Deprecate module pattern (factory) components #15145
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
ReactDOM: size: 0.0%, gzip: -0.0% Details of bundled changes.Comparing: 1e3364e...aa4d7ff react-dom
react-art
react-native-renderer
react-test-renderer
react-reconciler
Generated by 🚫 dangerJS |
|
The Relay Classic reference seems to be used in Relay Modern, but that's the only case in OSS that I've seen using this pattern. |
|
I have a diff open internally to fix the Relay caller. |
gaearon
approved these changes
Mar 19, 2019
facebook-github-bot
pushed a commit
to facebook/relay
that referenced
this pull request
Mar 19, 2019
Summary: The factory component pattern is about to be deprecate in: facebook/react#15145 This change makes it so that React will call this constructor with `new` as if it is a class component instead of just calling it as a function component. There might be a slight perf penalty to doing this my understanding is that this is not the preferred path anyway. Reviewed By: kassens Differential Revision: D14516681 fbshipit-source-id: 751890a98639687b208633f2e4c8e71e5df60776
Merged
This was referenced Aug 17, 2019
This was referenced Aug 24, 2019
This was referenced Mar 10, 2020
This was referenced Mar 18, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is part of reactjs/rfcs#107 but it's not the only reason we want to deprecate it.
It requires a fairly complex code path in React that is forked from how class components are initialized. It makes function components slower, adds code bloat to React and is a maintenance burden.
It was really kind of supported from the beginning. It was originally added at a time where createClass and class-like abstractions were more popular. We also hit quirks with compile-to-JS languages when we changed how our class abstractions worked. E.g. we had to make accommodations to support ScalaJS. To avoid future problems, we kept this style of class working since it's really the simplest form of constructor in JavaScript.
However, since then when we ultimately supported both ES classes (must be called with
new) and arrow function components (cannot be called withnew), we had to start getting more selective about which components we call withnewand which we don't.In practice, I don't think this pattern has been widely used even by compile to JS languages or class-like abstractions.
In any official capacity, its support has only been briefly noted at the bottom of the React v0.13.0 Beta 1 post.
It is currently used by at least Relay Classic so some libraries will need to upgrade.
A neat trick is that you can almost always just add:
This tricks React's class detection into thinking it's a class and we'll call it with
new, which means that this doesn't work on arrow functions.