Closed MangelMaxime closed 1 year ago
This doesn't look ready!? because I see a lot of react-dom
specific stuff still in here like Fable.React.Standard.fs, Props, Extensions etc... Now if Fable.ReactNative depends on Fable.React, they will have access to div
and h1
but they can't use them because they are react-dom
specific..
Ah yes, indeed.
I thought that react-native was accepting the same components as the one from the browser my bad.
I will update the PR.
I gave this split a try locally but it was soo messy because of the SSR stuff everywhere using compiler directives to generate html elements on the server, but now these stuff have to go to fable-react-dom
or their own library?!
@MangelMaxime IIRC we never did the react/react-dom split at the end. Should we try to do it now that we are also splitting the types and the helpers?
@alfonsogarciacaro Because we are already doing a breaking changes with Fable.React.Types, indeed I think it would be a good opportunity to split the packages.
What was the main motivation to remove react-dom btw? For cleanness or to avoid Femto using warnings in projects that don't need react-dom (like react native projects)?
I think it was to have a clean binding in term of dependencies.
For example, native project doesn't need react-dom and it would probably also make it cleaner which package is responsible for what. As before everything was mixed together between F# specific code, bindings for the React.Dom or for React itself
Superseded by #234
Follow up on https://github.com/fable-compiler/fable-react/pull/169
The package split of
Fable.React
is ready, there is already a beta version of Fable.React.Dom published.I am waiting for a solution to Fable.Elmish.React split before realising everything to stable.