Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal : Linking API #56

Open
Freddy03h opened this issue Dec 22, 2022 · 5 comments
Open

Proposal : Linking API #56

Freddy03h opened this issue Dec 22, 2022 · 5 comments

Comments

@Freddy03h
Copy link
Member

Linking API

For my project I created a linking API but I'm far from zero cost binding, since ReScript 10 and optional record attribute, it's seems less shitty and I think it's cool to discuss to have experts opinions about it.

Proposal

type routeName = string

type rec pathConfig = {
  path?: string,
  exact?: bool,
  initialRouteName?: routeName,
  screens?: screens,
}
and screens = Js.Dict.t<pathConfig>

type config = {
  initialRouteName?: routeName,
  screens: screens,
}

type t = {
  enabled?: bool,
  prefixes: array<string>,
  config?: config,
}

type routeNameAndConfig = (routeName, pathConfig)

let makeScreens = (screens: array<routeNameAndConfig>): screens => screens->Js.Dict.fromArray

Example

let options = {
  prefixes: [WebConst.origin],
  config: {
    initialRouteName: "app",
    screens: [
      (
        "app",
        {
          screens: [
            ("news", {screens: [("newsList", {path: ""})]->makeScreens}),
            (
              "planning",
              {
                screens: [
                  (
                    "planningNav",
                    {
                      screens: [
                        ("planningNewList", {path: "planning/news"}),
                        ("planningList", {path: "planning"}),
                      ]->makeScreens,
                    },
                  ),
                ]->makeScreens,
              },
            ),
            (
              "catalogue",
              {
                screens: [
                  (
                    "catalogueNav",
                    {
                      screens: [
                        ("seriesList", {path: "series"}),
                        ("authorsList", {path: "authors"}),
                        ("publishersList", {path: "publishers"}),
                      ]->makeScreens,
                    },
                  ),
                ]->makeScreens,
              },
            ),
          ]->makeScreens,
        },
      ),
      (
        "modalNav",
        {
          screens: [
            ("volumeDetail", {path: "volumes/:id"}),
            ("editionDetail", {path: "editions/:id"}),
            ("serieDetail", {path: "series/:id"}),
            ("publisherDetail", {path: "publishers/:id"}),
            ("authorDetail", {path: "authors/:id"}),
          ]->makeScreens,
        },
      ),
      (
        "collectionPublic",
        {
          initialRouteName: "collectionPublicNav",
          path: "user/:username",
          screens: [
            (
              "collectionPublicNav",
              {
                screens: [
                  ("collectionPublicList", {path: "collection"}),
                  ("planningPersoPublicList", {path: "planning"}),
                  ("missingPublicList", {path: "missing"}),
                  ("wishPublicList", {path: "wish"}),
                ]->makeScreens,
              },
            ),
            ("collectionPublicEdition", {path: "edition/:editionId"}),
          ]->makeScreens,
        },
      ),
    ]->makeScreens,
  },
}
@MoOx
Copy link
Member

MoOx commented Dec 30, 2022

Is there a real interest to define screens = Js.Dict.t<pathConfig> ?
If that's a abstract type (type screens;) makeScreen could be zero cost, right ?

@Freddy03h
Copy link
Member Author

Freddy03h commented Feb 14, 2023

I don't know how to do that…

If screens isn't defined, it seems compiler take the first declared definition of screens and made others as errors.

@MoOx
Copy link
Member

MoOx commented Mar 21, 2023

Is this needed with #58 ?

@Freddy03h
Copy link
Member Author

Linking is not blocking for a new release, because this API doesn't exist yet.

I tested it on 10.0, I can give a new try with 10.1

@Freddy03h
Copy link
Member Author

This could help us : rescript-lang/rescript-compiler#6545

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants