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

WIP: Repo split #171

Closed
wants to merge 1 commit into from
Closed

WIP: Repo split #171

wants to merge 1 commit into from

Conversation

MangelMaxime
Copy link
Member

Follow up on #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.

- Remove react-dom API
- Add femto metadata
@Zaid-Ajaj
Copy link
Member

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..

@MangelMaxime
Copy link
Member Author

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.

@MangelMaxime MangelMaxime changed the title Repo split WIP: Repo split Jul 24, 2019
@Zaid-Ajaj
Copy link
Member

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?!

@alfonsogarciacaro
Copy link
Member

@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?

@MangelMaxime
Copy link
Member Author

@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.

@alfonsogarciacaro
Copy link
Member

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)?

@MangelMaxime
Copy link
Member Author

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

@alfonsogarciacaro
Copy link
Member

Superseded by #234

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

Successfully merging this pull request may close these issues.

3 participants