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

Split into multiple packages? #60

Open
cknitt opened this issue Sep 25, 2022 · 8 comments
Open

Split into multiple packages? #60

cknitt opened this issue Sep 25, 2022 · 8 comments

Comments

@cknitt
Copy link
Member

cknitt commented Sep 25, 2022

  1. With JSX4 bringing breaking changes, the JSX3 bindings have been moved into a separate namespace ReactV3. I was wondering if this ReactV3 namespace shouldn't better be provided by some compatibility package.
  2. @rescript/react currently includes bindings for both react and react-dom and also has both as peer and dev dependencies. However, not every React project is also using React DOM. E.g. React Native projects aren't. So IMHO react-dom bindings should go into their own package.
  3. RescriptReactRouter into a separate package? #33 mentions the idea to split out ReScriptReactRouter into a separate package.

If we did all that, we'd end up with something like

  • @rescript/react
  • @rescript/react-dom
  • @rescript/react-jsx3-compat
  • @rescript/rescript-react-router (or just rescript-react-router?)

@mattdamon108 @cristianoc What do you think? How would such a split affect the PPX?

@cristianoc
Copy link
Contributor

The issue is while transitioning to V4 you might want to do that gradually.
That means having both V3 and V4 used in the same project.
So you install latest rescript-react and use open ReactV3 where needed.

@mununki
Copy link
Member

mununki commented Sep 26, 2022

I think that it is a better choice that ReactV3 is shipped with the latest rescript-react because it is could be used in the same project.
Regarding dom and router, IMHO, splitting rescript-react and rescript-react-dom could get some benefit for users to install separately as per their project needs. e.g. React Native as @cknitt says. That is what the react team does. The same story for rescript-react-router.

@cknitt
Copy link
Member Author

cknitt commented Sep 26, 2022

@mattdamon108 Ok, but ReactV3 also includes ReactDOM.

Would it be possible to have

  • @rescript/react (including ReactV3 compatibility module - without the DOM stuff)
  • @rescript/react-dom (including ReactDOMV3 compatibility module)
  • @rescript/rescript-react-router

?

@mununki
Copy link
Member

mununki commented Sep 27, 2022

@cknitt Yes, it is possible, but not a simple task as we're expecting. Currently ReactDOM has not only react-dom apis, also has dom related apis, such as Ref, domProps, createElement for dom element. If we make a decision to align to the react, react-dom, and separate bindings accordingly. We have to move all the unrelated modules and types to React.res and ReactV3.res. I'm afraid it would make users have to change their existing code much more due to this splitting.

@mununki
Copy link
Member

mununki commented Sep 27, 2022

First thing came to mind is that ReactDOM.Ref.* -> React.DOM.Ref.* seems inevitable.

@mununki
Copy link
Member

mununki commented Sep 27, 2022

V3 -> V4 migration period seems quite a good timing to split the bindings though.

@cristianoc
Copy link
Contributor

There is a change budget for each transition, the more changes one introduces, the harder the transition becomes.
I have pushed a lot trying to not have to change rescript-react at all during the V3 -> V4 transition, but it was just too difficult.
I'm afraid there's no budget for more changes at the same time.

In any case, this change requires deprecation, following by changes later on. So will have to be split across 2 phases.

@cristianoc
Copy link
Contributor

Another possible direction, which was explored for a while, but can be explored more if now things are more stable with JSX V4, is to move more of rescript-react into the compiler.
That might open the way to only have the rest (ie what's not in the compiler) in separate packages.

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

3 participants