Closed gaearon closed 6 years ago
aweary
commented
7 years ago ReactDOM fixes, if @jquense @nhunzaker @aweary want to release any.
I think at least https://github.com/facebook/react/pull/8575 and https://github.com/facebook/react/pull/7359 should be included in 15.5. They're both close to being merged.
nhunzaker
commented
7 years ago @jquense we probably want to merge yours first (#8575). #7359 relies on ChangeEventPlugin to keep the value attribute in sync with the value property. We'll need to re-evaluate #7359 with those changes.
jamiebuilds
commented
7 years ago
- React.createClass will be moved to a separate package
- React.createFactory will be moved to a separate package
- React.DOM.* factories will be moved to a separate package
All these new packages, maybe you need a tool for managing so many packages in a single repo... :wink:
sophiebits
commented
7 years ago As long as it doesn't make our UMD builds harder I'm on board with lerna. Someone want to send a PR?
gaearon
commented
7 years ago Pretty sure we've reached peak harder and it's downhill from there.
jamiebuilds
commented
7 years ago @gaearon Challenge accepted.
@spicyj jk I won't make it harder, I'll throw something together for you
tizmagik
commented
7 years ago This is awesome! Excited about what's ahead in React 16. Also glad I won't have to manually create a minified build of React for server render. 😅
Curious, any idea about how much larger the bundle is with React Fiber?
klzns
commented
7 years ago Why is this scratched?
Make setState async by default. Remove the attribute whitelist. Stateful functional components. New context API.
If it's just a stylistic choice, it's confusing. It's like a double negative hehe
jquense
commented
7 years ago Ya! look great y'all. one thought related to flat bundles. it's harder to write certain types of tooling without access to internal apis. Specifically thinking about test libs, the few I maintain invariably need to touch a bunch of internal apis when test utils fall short. it's a bit of a niche use case tho asandthe cost of using those Apis is well understood and aren't used in production apps
quantizor
commented
7 years ago If you guys do want to switch to lerna, I've been working on rollup scripting to make flat files of lerna packages. Would be happy to help out.
gaearon
commented
7 years ago Curious, any idea about how much larger the bundle is with React Fiber?
Right now it's roughly the same size while implementing more features (async scheduling, error boundaries, fragments, portals). We haven't worked on optimizing its size so I think we can reduce it further too. We'll likely do so after the initial release.
Another promising (IMO) area is Fiber's support for custom renderers. If ReactDOM's tradeoffs don't match what your product needs, it should be much easier to create a custom DOM renderer that, for example, doesn't ship with the synthetic event system. Fiber makes custom renderers way easier to create, while giving you all component features out of the box.
Hurtak
commented
7 years ago 'Stateful functional components' is there some issue where I can read more about this?
swernerx
commented
7 years ago When you go the flat bundle route - which I definitely appreciate - it would be awesome to offer a modern bundle for Node v6 / ES2015 capable browsers, too.
I did some work on this topic in http://npmjs.com/package/prepublish - which effectively produces flat bundles for different output scenarios. Basically a configured wrapper around Rollup/Babel/Buble.
I also thought of adding specific "modern" entries to the package.json so that bundles like Webpack can make use of this e.g. main:modern or module:modern. I think something like this would be definitely interesting for React (especially in context of SSR apps where you can target Node >= v6).
nakamorichi
commented
7 years ago Agree with @swernerx . It's about time to migrate to ES6.
gaearon
commented
7 years ago @swernerx This is an interesting direction and we may explore it in the future. Right now the browser support for ES6 is increasing but many features are sufficiently slower than ES5 counterparts, just because nobody had time to optimize it yet. I know V8 team is hard at work fixing this, and I’d rather look into it again after evergreen browsers are mostly fast when using ES6.
gaearon
commented
7 years ago 'Stateful functional components' is there some issue where I can read more about this?
No specific issue AFAIK. There are some old ideas in this repo if you’re interested, but they’re just that, ideas. There are numerous reasons we’re interested in having stateful functional components, I listed some here.
dtinth
commented
7 years ago Concerning the “flat bundles,” it would be great if the internals are still exposed one way or the other, because we at Taskworld sometimes monkey-patched React internals from userland code to have more fine-grained error messages and performance measurement.
What we did is we hooked into React’s internals and added some instrumenting code like this:
…
We also hooked into Redux and Reselect in similar ways for a unified development experience.
I know that this isn’t supported and internal APIs may break in any release (especially with Fiber coming), but unsupported is better than impossible 😄.
gaearon
commented
7 years ago we at Taskworld sometimes monkey-patched React internals from userland code to have more fine-grained error messages
This is supported by error boundaries in Fiber.
and performance measurement.
You can use ReactPerf for that.
I know that this isn’t supported and internal APIs may break in any release (especially with Fiber coming), but unsupported is better than impossible 😄.
Even better, let’s discuss the use cases and come up with supported APIs. 😉
swernerx
commented
7 years ago @gaearon It's about offering such a package format for modern clients (in parallel to the classic build - which is what the prepublish tool mentioned does). In the end React does not decide on the processing/bundling/output of the application. But if you transpile stuff you make the original ES6 code unaccessible for any user who wants to deploy for modern node or embedded browsers only.
swernerx
commented
7 years ago @gaearon "main" and "module" should always point to the ES5 bundles with either commonjs or esmodule outputs. But we are free to offer an alternative modern build keeping ES2015 stuff intact.
MilosRasic
commented
7 years ago Excuse my ignorance, but does removal of createMixin mean that all packages that rely on mixins will stop working until dependants switch to a HOC solution or will they be able to quickly switch to an alternate way to provide old-style mixins?
gaearon
commented
7 years ago Excuse my ignorance, but does removal of createMixin mean that all packages that rely on mixins will stop working until dependants switch to a HOC solution or will they be able to quickly switch to an alternate way to provide old-style mixins?
createMixin implementation looks like this:
function createMixin(mixin) {
return mixin;
}It was never documented, and only appeared in the API because we thought we might want to validate mixins in the future. Packages that somehow found out about it and started using it can just remove the createMixin call and use the mixin directly.
Most packages providing mixins don’t use createMixin. For those that do, this is a one-line change: just removing the useless function call.
It's about offering such a package format for modern clients (in parallel to the classic build - which is what the prepublish tool mentioned does)
Yes, I understand this. What I’m saying is if we offer this build, people will use it, and if performance is suboptimal, they will blame React. So we will wait until ES6 features are actually fast before providing a build that does that.
nakamorichi
commented
7 years ago @gaearon Migration to ES6 can be done in iterations, e.g., first convert all vars to either let or const, then other features that are supported without performance issues.
Also, there are two issues here: (1) syntax of the source code, and (2) syntax of the bundle. Is there a reason for not migrating the source to the latest standard - ES7/ES2016 - with the possibility of using staged features if deemed useful enough?
Syntax of the bundle is a totally separate issue, as the syntax of the bundle (or bundles) can be decided during the build step. I think it would be awesome to have separate bundles for each relevant standard, but I'm not sure how to achieve this in practice, or whether this can be achieved without unreasonable amount of work. Nevertheless, ES6 is here to stay, and the project ought to provide bundle targeting it, which naturally first requires converting the source to utilize its features.
gaearon
commented
7 years ago We are pragmatic in choosing both source and target languages, and are driven by pragmatic needs.
Migration to ES6 can be done in iterations, e.g., first convert all vars to either let or const, then other features that are supported without performance issues.
For the target bundle, what exactly would that accomplish? There are no benefits to the end users in this case, and there are downsides (less browser support, more fragmentation and potential surface area for bugs).
Is there a reason for not migrating the source to the latest standard - ES7/ES2016 - with the possibility of using staged features if deemed useful enough?
We are using new features in newly written code. There is very little benefit, in our opinion, to rewrite existing code with new features since this also introduces a risk of new bugs. It’s a nice way to ramp up contributors, but as noted in this issue, we have already rewritten most of React so it doesn’t make sense to me to convert the old code now.
zalmoxisus
commented
7 years ago @gaearon
Even better, let’s discuss the use cases and come up with supported APIs.
It would be great to have an API to detect if an object is a Synthetic Event. For Redux, usually users are passing events as action payloads (which also redux-actions does), even when not using them. It breaks the ability to access them while sending to the monitors. A simple solution was:
import SyntheticEvent from 'react/lib/SyntheticEvent';
// ...
const store = createStore(rootReducer, window.__REDUX_DEVTOOLS_EXTENSION__ && window.__REDUX_DEVTOOLS_EXTENSION__({
serialize: {
replacer: (key, value) => {
if (value && value instanceof SyntheticEvent) return '[Event]';
return value;
}
}
}));Though maybe we should just encourage using event.persist when not providing event data explicitly.
gaearon
commented
7 years ago Though maybe we should just encourage using event.persist when not providing event data explecitely.
This is the solution here.
nakamorichi
commented
7 years ago @gaearon I totally understand if code that may soon be deprecated is not rewritten, but is it really a good idea to, for example, continue using two module syntaxes side-by-side in newly written code? I see some source files even combining both. For parts that are necessary for supporting Node, using Node's module syntax is of course understandable. Personally I feel quite strongly about unnecessarily mixing two competing module handling mechanisms - particularly in newly written code, and particularly when talking about a standard- and a non-standard one.
One point, not sure if actually relevant, came to my mind: React is one of the "hottest" libraries out there in the JavaScript world, and if React decided to fully utilize the latest standardized ES features (preferably with strict style guidelines), this might incentivize browser manufacturers to hasten their optimization efforts. React could show way for, not only other UI libraries out there, but for the whole JavaScript ecosystem. Maybe slightly optimistic, but 😺
gaearon
commented
7 years ago using two module syntaxes side-by-side in newly written code? I see some source files even combining both.
We are using CommonJS exclusively right now (mostly due to Facebook build pipeline limitations). I think you might be confusing Flow's import type syntax with ES modules.
nakamorichi
commented
7 years ago Oh, haven't used Flow so that kind of syntax was new for me.
dtinth
commented
7 years ago @gaearon Thanks for the suggestions. I am excited about the error boundaries!
I find off-the-shelf solutions (such as ReactPerf) sometimes not to be suitable. For instance, I monkeypatched several libraries to be able to construct a table that shows how much time (in percentage) is spent in:
react-dom/lib/ReactReconciler)react-dom/lib/ReactInstrumentation)reselectHaving this data gives a high level overview of where I should focus on optimizing.
However, let’s not focus on a specific problem (performance, error boundaries)—these are just examples. I believe there are other unforeseen use cases where monkeypatching the internals could be useful.
Here’s another situation where I monkeypatched React’s internals: I want to make React warnings appear as a popup in the DOM instead of in the console, because sometimes I develop my user interface without the devtools on.
I accomplished this by monkeypatching fbjs/lib/warning to display a popup instead of using console.error(). This would be very hard to accomplish if React is packaged as a flat bundle—I would have given up that idea. Exposing the internals allows for experimentation.
gaearon
commented
7 years ago I find off-the-shelf solutions (such as ReactPerf) sometimes not to be suitable. For instance, I monkeypatched several libraries to be able to construct a table that shows how much time (in percentage) is spent in: [...]
I may be wrong but I believe all this data is already exposed via ReactPerf.getLastMeasurements().
I want to make React warnings appear as a popup in the DOM instead of in the console, because sometimes I develop my user interface without the devtools on.
So do we which is why we intend to show a UI (https://github.com/facebook/react/pull/7360) by default in React 16. I forgot to add this to the umbrella.
let’s not focus on a specific problem (performance, error boundaries)—these are just examples. I believe there are other unforeseen use cases where monkeypatching the internals could be useful.
I agree it can be useful. However the problem is, once you've monkeypatched it to your convenience, you won't come back filing an issue and gathering support for it from the community. As a result everyone ends up with local hacks that break every few versions, and no permanent solutions, while the maintainers aren't even aware this is something people want. I would rather prefer we have more discussions like this one, where you explain the use cases, and we either point out or provide (possibly unstable) hooks.
dtinth
commented
7 years ago @gaearon That makes sense, and I agree with your sentiment. Although I usually treat open-source projects with the “you want it, you do it” mindset (which is why I kinda like to start by experimenting alone), making them an issue could bring more benefit to the project and community. ❤️
MHerszak
commented
7 years ago I can see my browser console showing so many warnings just because of react-router. :) And also other packages that I use which still make use of createClass.
gaearon
commented
7 years ago We likely won’t be firing multiple warnings, just a single one (with names of the first few classes). We don’t want to spam the console.
guotie
commented
7 years ago when does it release
gaearon
commented
7 years ago We don't know yet but I'd say likely within three months.
lax4mike
commented
7 years ago +1 for Stateful functional components. I don't know what the API would look like, but it has to be more elegant than es6 classes.
markudevelop
commented
7 years ago that's really awesome cant wait to get Fiber means we can finally improve the renderToString to achieve better SSR performance? Async renderToString will be the best thing for me right now went from 2 servers to 10 just because it's not async.
gaearon
commented
7 years ago Fiber doesn't currently bring anything new for SSR.
The plan mentions that if we switch to flat bundles, the synchronous renderToString perf should get better by default because you won't have to envify your code manually (and most people don't). However this is not related to Fiber or SSR being asynchronous.
ColCh
commented
7 years ago What about stateless components optimization aka function components? They are pure, and they got rendered every time, not like Classes with PureRenderers
Definition of stateless component is here src/renderers/shared/stack/reconciler/ReactCompositeComponent.js#L38. It looks like regular component. May be it should look like React.PureComponent ?
Sorry if I don't understand some points of stateless components
MilosRasic
commented
7 years ago To be honest, stateful functional components seems to be just another way to write what you can already write using classes. I'd be far more hyped about stateless functional component optimizations that have been hinted at in the past.
gaearon
commented
7 years ago @ColCh You can refer to the past discussion about this which was pretty controversial: https://github.com/facebook/react/pull/6914
@MilosRasic While stateful functional components are "just another way" to write the same code, there are important differences that make them interesting to us. I mentioned this earlier in the thread.
phaistonian
commented
7 years ago ETA for 16?
gaearon
commented
7 years ago In a few months.
aweary
commented
7 years ago @gaearon what is the status of PropTypes? We have previously stated that they were in "maintenance mode" and turned away feature requests, but we haven't been consistent about that. Do we plan to continue adding features to PropTypes?
gaearon
commented
7 years ago @aweary I don't think so, but do you have any particular ones in mind?
aweary
commented
7 years ago @gaearon no, I'm mostly asking in regards to the handful of PRs we have open for PropTypes (on mobile, can't link).
aweary
commented
7 years ago 
danielearwicker
commented
7 years ago How about moving state/setState into a separate library? Core React becomes props-only. Statefulness can then be added on in various ways, with "per component state" as just one option. Derived class such as StatefulComponent would serve as base class for any component wanting intrinsic state.
gaearon
commented
7 years ago @danielearwicker
Let's keep this thread focused on 16 roadmap and not use it as a place for generic feature requests or suggestions. Otherwise everyone will pile on the features they want to see which have no relationship to the roadmap. 😉
This list might change, just putting it out there as the first draft. Posting these together since they're related, and we don't plan more 15.x releases after 15.5 anyway.
To put these changes in context, we have a few goals:
(Click to show)
Here’s a speculative list of changes we think of doing in these releases:
Past Releases
I’ve moved these to the end of this post.
16 Final
still exists after RC2turns out to be polyfill.io bug, https://github.com/Financial-Times/polyfill-service/issues/1299) https://www.reddit.com/r/javascript/comments/6pqrz5/comment/dmrl0nhunstable_prefix fromunstable_createPortaland alias it @gaearon https://github.com/facebook/react/pull/10675rendercreatePortal()/umd/*rather thansebmt/*)TODO: Add any bugs discovered while testing RC.
16 Wishlist
unstable_forceUpdateDeep()and then change https://github.com/gaearon/react-deep-force-update to use it)setStateupdater form (https://twitter.com/nishb1/status/852542873803345920) (@gaearon will follow up)Past Releases
`React.DOM.*` factories (will be moved to a separate package, https://github.com/facebook/react/pull/8356)**We forgot to do it. Moving to 15.6** - [ ]`React.createMixin` (will be removed, https://github.com/facebook/react/pull/8853)**We forgot to do it. Moving to 15.6** - [x] `React.propTypes` (will be moved to a separate package) - [x] Deprecate React addons https://github.com/facebook/react/issues/9207 - [x] Decide how to handle all of this with the UMD addons build - [x] Fix this bug https://github.com/facebook/react/issues/9351reviewupdated and merged) - [x] Make sure input variables (props, state) point to the correct values for each lifecycle. Example where this isn't the case for `componentWillMount`: https://jsfiddle.net/m3pL3yaj/ (@acdlite) (fixed in #10481) - [x] `select`'s onChange event fires with incorrect selectedIndex, value (https://github.com/facebook/react/issues/10420 @sebmarkbage) - [x] How do we ensure weak minifiers don't ship the bundle twice? https://github.com/facebook/react/issues/9589 (@flarnie, @trueadm) (fixed in https://github.com/facebook/react/pull/10446) - [x] Bug: SSR has false positive warnings for SVG tags #10415 (@spicyj) (fixed in https://github.com/facebook/react/pull/10452) - [x] Bug: Unexpected cross-domain error passed to `componentDidCatch` #10441 (@bvaughn) (fixed in https://github.com/facebook/react/pull/10447) - [x] Warn when nesting a 15 tree inside 16 (@spicyj https://github.com/facebook/react/pull/10434) (fixed in https://github.com/facebook/react/pull/10434) - [x] undefined is not a function (evaluating 'owner.getName()') https://github.com/facebook/react/issues/10443 - [x] Regressions reported in beta - [x] The server renderer crashes in production with inline styles. (https://github.com/facebook/react/issues/10299, fixed by https://github.com/facebook/react/pull/10300) - [x] The server renderer doesn't yet support returning arrays and strings from components (fixed by #10221) - [x] The server renderer still renders `data-reactid` somewhat unnecessarily. (https://github.com/facebook/react/issues/10306) (@gaearon) - [x] Potentially fixed by https://github.com/facebook/react/pull/10339 (@gaearon) - [x] In some cases `Error: null` is reported instead of the real error. (https://github.com/facebook/react/issues/10321) [decision: update the error message] (@acdlite) - [x] Shallow renderer doesn't implement `unstable_batchedUpdates`. [decision: team seems to be leaning away from doing this; discussion in #10355] - [x] [s-m] `shouldComponentUpdate` with functional components [decision: delete it for now, add it in a minor] (@sebmarkbage) https://github.com/facebook/react/pull/10371 - [x] There is a report that Google crawler can’t render the page using 16 ([link](https://www.reddit.com/r/javascript/comments/6pqrz5/react_16_beta/dkrgvzj/?utm_content=permalink&utm_medium=front&utm_source=reddit&utm_name=javascript)). (@flarnie) - [x]Check if https://github.com/facebook/react/issues/10405 is a real regression(No, it's been fixed looks like.) - [x] [s-m] Ensure type validation didn't regress when we enabled new features https://github.com/facebook/react/issues/9577 (@gaearon) - [x]Decide if we want to break value attribute syncing behavior (https://github.com/facebook/react/pull/10150)[decided to postpone until 17] - [x] [s-m] Decide if we want to stop calling `componentDidUpdate` from shallow renderer (https://github.com/facebook/react/pull/10372) - [x] Decide: what do we do about polyfills? - [x] Map/Set (need to throw early, @gaearon) https://github.com/facebook/react/pull/10356 - [x] Object.assign (keep or assume it's there?) https://github.com/facebook/react/pull/10280 [decision: keep it bundled for now] - [x] rAF [decision: keep it required] (Maybe use the same approach/standard as Relay? https://facebook.github.io/relay/docs/relay-modern.html#javascript-environment-requirements) - [x] Big missing pieces - [x] Add server rendering and reviving - [x] Add shallow renderer - [x] We seem to be decoupling shallow renderer from ReactDOM. However in 15 `findDOMNode()` works inside of shallow renderer because it contains ReactDOM injections. Is this going to be a breaking change? (@gaearon) [decision: let's not support this] - [x] Decide on whether to include warning whitelisting/blacklisting (@bvaughn) [decision: not in 16.0] - [x] Maybe: Switch to flat bundles (no more `react-dom/lib/*`, internals are truly private) - [x] Decide: plan forward for popular projects depending on internals (`react-native-web`, `react-tap-event-plugin`) (might not block final) - [x] `EventPluginHub` is "dangerously" exported from flat bundle for tap event plugin - [x] `react-native-web` probably needs more internals, coordinate with @necolas (done in https://github.com/facebook/react/pull/10138) - [x]Support `class` and `for` https://github.com/facebook/react/pull/10169 (@gaearon)[decision: not gonna do this now] - [x] Feature parity for renderers - [x] Shallow renderer supports strings and arrays - [x] Server renderer supports strings and arrays - [x]Server renderer supports error boundaries[doesn't make sense conceptually right now] - [x] Decide on whether to put `react-current-owner` in its own package to reduce issues caused by npm duplication [not now] - [x] Decide on DOMServer entry points (`react-dom/server` and `react-dom/node-stream` seem inconsistent with each other. Why is only one of them `server`?) (@gaearon) https://github.com/facebook/react/pull/10362 * These were configured separately for Prepack. One target includes both the pure JS APIs and the Node APIs and the other only includes the pure JS APIs. We could combine them into a single `react-dom/server` entry point and add a new `renderToString` method on it. - [x] Decide: Do we care about catching errors in events in the initial release? [no] - [x] Error messages (@flarnie) (Dan: I moved this back to blockers because I don't think we can release with unclear messages. Error boundaries are a huge change in open source and we must have documentation and a link before we start unmounting roots.) - [x] "You can add an error boundary" message should link to docs - [x] duplicate key warning for children with same keys is out of date; claims child will be ignored but now we will only render second one. (easy to add to 16 final or sooner) (@sebmarkbage) - [x] Verify that the bundles produced are valid in strict mode. https://github.com/facebook/react/issues/10294#issuecomment-319490960 (@bvaughn) - [x] Testing the Beta: (React team in general) - [x] Share the beta and proposed release date with library authors several weeks in advance - [x] Triage any issues reported with beta.