React 16 RC

Question

React 16 RC

bvaughn opened this issue 7 years ago · 254 comments

The third React 16 RC is now available for public testing. 🎉

Installation Instructions

The RC has been published to NPM with the tag "next". Regular NPM installs will continue to use the 15.6 release. To install the RC use:

yarn add react@next react-dom@next

Or:

npm install --save react@next react-dom@next

What Does React 16 Mean for You?

React 16 is the first release that ships with a rewrite of the React core (previously codenamed “Fiber”). This rewrite had a few goals:

Remove old internal abstractions that didn’t age well and hindered internal changes.
Let us ship some of the most requested features like returning arrays from render, recovering from component errors, and readable component stack traces for every error.
Enable us to start experimenting with asynchronous rendering of components for better perceived performance.

This initial React 16.0 release is mostly focused on compatibility with existing apps. It does not enable asynchronous rendering yet. We will introduce an opt-in to the async mode later during React 16.x. We don’t expect React 16.0 to make your apps significantly faster or slower, but we’d love to know if you see improvements or regressions.

JavaScript Environment Requirements

React 16 depends on the collection types Map and Set. If you support older browsers and devices which may not yet provide these natively (eg <IE11), consider including a global polyfill in your bundled application, such as core-js or babel-polyfill.

A polyfilled environment for React 16 using core-js to support older browsers might look like:

import 'core-js/es6/map';
import 'core-js/es6/set';

import React from 'react';
import ReactDOM from 'react-dom';

ReactDOM.render(
  <h1>Hello, world!</h1>,
  document.getElementById('root')
);

React also depends on requestAnimationFrame (even in test environments). A simple shim for testing environments would be:

global.requestAnimationFrame = function(callback) {
  setTimeout(callback, 0);
};

Points of Interest

This is a complete rewrite of React but we expect it to work with your existing code. If you fixed all deprecation warnings introduced in 15.x, the 16 beta should work for you.
Third party libraries that relied on deprecated or unsupported APIs may need updates to work correctly with this new release. Now is a good time to file issues against libraries that have problems. (And tell us if we broke something!)
We are particularly interested in hearing about performance differences you notice between 15.x and 16.x. We don't expect any massive changes but would love to know about improvements or regressions. Please report them here!
The server renderer has been completely rewritten, and now offers a streaming mode (ReactDOMServer.renderToNodeStream() and ReactDOMServer.renderToStaticNodeStream()). Server rendering does not use markup validation anymore, and instead tries its best to attach to existing DOM, warning about inconsistencies. And there is no data-reactid anymore! This server renderer code is still very new, so it is likely to have issues. Please report them.
Hydrating a server rendered container now has an explicit API. Use ReactDOM.hydrate instead of ReactDOM.render if you're reviving server rendered HTML. Keep using ReactDOM.render if you're just doing client-side rendering.
React Native follows a different release cycle and will update to the beta in a future release. (It's already using an alpha release but not yet using Fiber.)

Breaking Changes

Error Handling

Previously, runtime errors used to put React into a broken state and produce cryptic errors. React 16 fixes this by introducing a special kind of components called “error boundaries”. Error boundaries can catch runtime errors in a component tree, log them, and display a fallback UI instead.
If there is an uncaught error in a component, and there is no error boundary up in the tree, the whole component tree will be unmounted. This helps avoid very nasty bugs where the UI has been corrupted due to an error, but it means that you need to add a few error boundaries to your app to handle the errors gracefully.
React 15 had a very limited undocumented support for error boundaries with a different method name. It used to be called unstable_handleError, but has been renamed to componentDidCatch.

You can learn more about the new error handling behavior here.

Scheduling and Lifecycle

ReactDOM.render() and ReactDOM.unstable_renderIntoContainer() now return null if called from inside a lifecycle method.
- To work around this, you can either use the new portal API or refs.
setState:
- Calling setState with null no longer triggers an update. This allows you to decide in an updater function if you want to re-render.
- Calling setState directly in render always causes an update. This was not previously the case. Regardless, you should not be calling setState from render.
- setState callback (second argument) now fires immediately after componentDidMount / componentDidUpdate instead of after all components have rendered.
When replacing <A /> with <B />, B.componentWillMount now always happens before A.componentWillUnmount. Previously, A.componentWillUnmount could fire first in some cases.
Previously, changing the ref to a component would always detach the ref before that component's render is called. Now, we change the ref later, when applying the changes to the DOM.
It is not safe to re-render into a container that was modified by something other than React. This worked previously in some cases but was never supported. We now emit a warning in this case. Instead you should clean up your component trees using ReactDOM.unmountComponentAtNode. See this example.
componentDidUpdate lifecycle no longer receives prevContext param. (See #8631)
Shallow renderer no longer calls componentDidUpdate() because DOM refs are not available. This also makes it consistent with componentDidMount() (which does not get called in previous versions either).
Shallow renderer does not implement unstable_batchedUpdates() anymore.

Packaging

There is no react/lib/* and react-dom/lib/* anymore. Even in CommonJS environments, React and ReactDOM are precompiled to single files (“flat bundles”). If you previously relied on undocumented React internals, and they don’t work anymore, let us know about your specific case in this issue, and we’ll try to figure out a migration strategy for you.
There is no react-with-addons.js build anymore. All compatible addons are published separately on npm, and have single-file browser versions if you need them.
The deprecations introduced in 15.x have been removed from the core package. React.createClass is now available as create-react-class, React.PropTypes as prop-types, React.DOM as react-dom-factories, react-addons-test-utils as react-dom/test-utils, and shallow renderer as react-test-renderer/shallow. See 15.5.0 and 15.6.0 blog posts for instructions on migrating code and automated codemods.
The names and paths to the single-file browser builds have changed to emphasize the difference between development and production builds. For example:
- react/dist/react.js → react/umd/react.development.js
- react/dist/react.min.js → react/umd/react.production.min.js
- react-dom/dist/react-dom.js → react-dom/umd/react-dom.development.js
- react-dom/dist/react-dom.min.js → react-dom/umd/react-dom.production.min.js

Known Issues

~~The server renderer crashes in production with inline styles. (#10299, fixed by #10300)~~
- Fixed in 16.0.0-beta.2
~~The server renderer doesn't yet support returning arrays and strings from components.~~
- Fixed in 16.0.0-beta.3
~~The server renderer still renders data-reactid somewhat unnecessarily. (#10306)~~
- Fixed in 16.0.0-beta.3
~~Shallow renderer doesn’t pass context to componentWillReceiveProps (to be fixed by #10342)~~
- Fixed in 16.0.0-beta.3
~~There is an issue with 'use strict' in older browsers (#10294 (comment))~~
- Fixed in 16.0.0-beta.3
~~In some cases Error: null is reported instead of the real error. (#10321)~~
- Fixed in 16.0.0-beta.3
~~There is a report that Google crawler can’t render the page using 16 (link).~~
- Fixed in 16.0.0-beta.3
Some popular third party libraries won’t work yet (e.g. Enzyme).
(Please report more issues in this thread.)

Updates

Released 16.0.0-beta.1 on July 24, 2017
Released 16.0.0-beta.2 on July 27, 2017
- Fix a crash in server rendering.
Released 16.0.0-beta.3 on August 3, 2017
- Fix strict-mode function scope problem (#10361)
- Better error log messaging and cross-origin handling (#10353, #10373)
- Shallow renderer improvements (#10372, #10342)
- Edge-case context bugfix (#10334)
- Single point of entry for server rendering (#10362)
- etc.
Released 16.0.0-beta.4 on August 8, 2017
- Warn about unresolved function as a child. #10376
- Remove data-reactid and data-react-checksum from whitelist. #10402
- New test renderer API features (disabled via feature flag, for now). #10377
- And some other minor updates to slightly reduce bundle size.
Release 16.0.0-beta.5 on 2017-08-08
- Fix bugs related to unmounting error boundaries #10403
- Enable new fiber ReactTestRenderer API methods; (previously disabled behind a feature flag) #10410
Released 16.0.0-rc.1 on September 6, 2017
- Fix error: undefined is not a function (evaluating 'owner.getName()') (@fxfactorial in #10448 and @bvaughn in #10520)
- Improve error message when ReactDOM loads without React (@aweary in #10449)
- Warn when nesting 15 subtree inside 16 (@sophiebits in #10434)
- Don't warn about casing in SSR for non-HTML NS (@sophiebits in #10452)
- Throw error to warn of mistaken loading of prod + dev React bundles (@flarnie in #10446)
- Reset instance vars before calling commit phase lifecycles (@acdlite in #10481)
- Warn if event listener is not a function (@aweary in #10453)
- Fix bug where 1k+ react roots would cause error (@acdlite in #10574)
- Allow passing some "unknown" attributes through to DOM components (@nhunzaker in #10385 , #10564 , #10495 and others)
- Fix bug where <select> elements defaulted to first option, even when it was 'disabled'. (@aweary in #10456 and @nhunzaker in #10142)
Released 16.0.0-rc.2 on September 6, 2017
- Fix bug where React npm packages would throw an exception on startup in browsers not supporting const natively (@sophiebits in #10631)
Released 16.0.0-rc.3 on September 14, 2017
- Report bad dead code elimination to React DevTools (@gaearon in #10702)
- Fix false positive warning when hydrating SVG after SSR (@gaearon in #10676)
- Add a warning about non-lowercase custom attributes (@gaearon in #10699)
- Fix a memory leak (@gaearon in #10680)
- Remove deprecated entry point for the shallow renderer (@gaearon in #10682)
- Remove undocumented TestUtils methods (@gaearon in #10681)
- Add ReactDOM.createPortal() as an “official” API without the unstable prefix (@gaearon in #10675)
- Don’t repeat Object.assign polyfill twice (@gaearon in #10671)

leecade commented 7 years ago

🔥

👎3

Answer 1 · 2017-07-26T20:32:54.000Z

In regards to:

There is no react/lib/* and react-dom/lib/* anymore. Even in CommonJS environments, React and ReactDOM are precompiled to single files ("flat bundles"). If you previously relied on undocumented React internals, and they don't work anymore, let us know about your specific case in this issue, and we'll try to figure out a migration strategy for you.

We have been relying on https://github.com/electrode-io/electrode-react-ssr-caching which monkey-patches the React render. Any suggestions as to how to make it work with v16?

Used imports:

const ReactCompositeComponent = require("react-dom/lib/ReactCompositeComponent");
const DOMPropertyOperations = require("react-dom/lib/DOMPropertyOperations");

Thank you.

Answer 2 · 2017-07-26T20:47:41.000Z

Maybe @aickin can comment on the feasibility of integrating a caching solution directly into the server renderer?

Answer 3 · 2017-07-26T20:53:19.000Z

This initial React 16.0 release is mostly focused on compatibility with existing apps. It does not enable asynchronous rendering yet. We will introduce an opt-in to the async mode later during React 16.x.

Is there any way to manually enable asynchronous rendering in this beta?

Answer 4 · 2017-07-26T20:58:33.000Z

@verkholantsev Afaik there is an option. Or will be.

Answer 5 · 2017-07-26T21:01:06.000Z

@TrySound Could you tell more about this option? Or could you tell me in what direction should I start my research about it?

Answer 6 · 2017-07-26T21:12:33.000Z

@verkholantsev We'll provide info about enabling async once we think it's ready for testing. We're still experimenting on it internally.

Answer 7 · 2017-07-26T21:50:44.000Z

Can I import SynteticEvent from flat bundle?

Answer 8 · 2017-07-26T22:05:42.000Z

This might be interesting: just tried it in our codebase. Using yarn to install the package, I get an error in HMR and from one of our dependencies, but using npm (I'm on 5.2.0), it works! 🎉

Answer 9 · 2017-07-26T22:16:21.000Z

Can I import SynteticEvent from flat bundle?

Not currently. What is your use case for it?

Using yarn to install the package, I get an error in HMR and from one of our dependencies, but using npm (I'm on 5.2.0), it works!

We’ll need more details to tell if something is wrong. I’d appreciate if you could provide a reproducing project (even if it only fails with Yarn).

Answer 10 · 2017-07-26T22:26:24.000Z

@gaearon

Not currently. What is your use case for it?

Ex.: I want to pass change event to parent when toggle button.
Or I want to modify event before pass to parent.

// pseudocode
onClickItem(event) {
  const newEvent = new SynteticEvent('change', { id: this.state.currentId })
  this.props.onChange(newEvent)
}

Answer 11 · 2017-07-26T22:44:51.000Z

So far, everything runs smoothly save for my test cases of rendered components, because they depend on:

import { mount, shallow } from 'enzyme';

which results in dependency errors like this:

react-dom is an implicit dependency in order to support react@0.13-14. Please add the appropriate version to your devDependencies. See https://github.com/airbnb/enzyme#installation

This is an app that was built from CRA - it is not ejected. This appears to be the only place in which we use enzyme (tests are run with react-scripts test --env=jsdom --coverage). Is there an equivalent of mount and shallow within Jest that I should be using?

Answer 12 · 2017-07-26T22:53:10.000Z

diegoddox/react-redux-toastr#150

Answer 13 · 2017-07-26T22:58:25.000Z

when react enable me to call API with any built in package like $http in angular, without force me to use staff like superagent or axios ..

Answer 14 · 2017-07-26T23:00:14.000Z

@muhammedMoussa : that is not a goal for React, and React will not be shipping a built-in HTTP client library.

Answer 15 · 2017-07-26T23:00:33.000Z

Let’s keep this discussion focused on 16 Beta. Thanks.

Answer 16 · 2017-07-26T23:14:12.000Z

A compiled list of all deprecations that have been removed from 15 -> 16 would be helpful as a checklist for upgrading.

Related: is the warning for unknown attributes (via the whitelist) still in place or will upgrading to 16 start adding them to the DOM without warning?

Answer 17 · 2017-07-26T23:17:34.000Z

A compiled list of all deprecations that have been removed from 15 -> 16 would be helpful as a checklist for upgrading.

I think it’s React.createClass, React.PropTypes, React.__spread, React.createMixin , and React.DOM.*. There are a few changes to entry points too (e.g. shallow renderer is now react-test-renderer/shallow, and test utils moved to react-dom/test-utils). I believe they all are mentioned in these blog posts:

Related: is the warning for unknown attributes (via the whitelist) still in place or will upgrading to 16 start adding them to the DOM without warning?

This is sort of up in the air right now. I think we’ll make a decision before shipping next beta.

Answer 18 · 2017-07-26T23:41:29.000Z

Do the flat builds not interfere with scope hoisting by the app bundlers? Just wondering, not sure if there is much to gain from that. I presume the bundler would have to figure out statically that there are parts of React that are not used by the app and can be removed, probably a very tall order.

Answer 19 · 2017-07-27T00:08:43.000Z

@wmertens The flat bundle is scope hoisted itself. You can continue to hoist it yourself. It's basically just concatenating the modules into one file and ensuring no variable name overlaps. That's fully compatible with any bundler above it.

Answer 20 · 2017-07-27T00:23:45.000Z

This is an app that was built from CRA - it is not ejected. This appears to be the only place in which we use enzyme (tests are run with react-scripts test --env=jsdom --coverage). Is there an equivalent of mount and shallow within Jest that I should be using?

For what it's worth, Enzyme will be supporting React 16 just like previous releases. There's a huge refactor underway which includes support for React 16.

Answer 21 · 2017-07-27T00:26:36.000Z

Our large application ran perfectly except for our unit tests that depend on enzyme. This looks like our biggest blocker at this point.

Answer 22 · 2017-07-27T01:32:53.000Z

Seems that react-dom/server doesn't work correctly with style in production mode . In dev all works fine.

const React = require('react')
const ReactServer = require('react-dom/server')
const foo1 = React.createElement("div", {
  className: "sign-link",
  id: "sign-layout-link",
  style: { position: 'absolute' }
});

ReactServer.renderToString(foo1)
TypeError: re is not a function
    at /Users/v7rulnik/projects/kupibilet/internals/kupibilet.ru/node_modules/react-dom/cjs/react-dom-server.production.min.js:1:7774
    at /Users/v7rulnik/projects/kupibilet/internals/kupibilet.ru/node_modules/fbjs/lib/memoizeStringOnly.js:23:32
    at f (/Users/v7rulnik/projects/kupibilet/internals/kupibilet.ru/node_modules/react-dom/cjs/react-dom-server.production.min.js:1:2423)
    at b (/Users/v7rulnik/projects/kupibilet/internals/kupibilet.ru/node_modules/react-dom/cjs/react-dom-server.production.min.js:1:3163)
    at e.renderDOM (/Users/v7rulnik/projects/kupibilet/internals/kupibilet.ru/node_modules/react-dom/cjs/react-dom-server.production.min.js:1:9665)
    at e.render (/Users/v7rulnik/projects/kupibilet/internals/kupibilet.ru/node_modules/react-dom/cjs/react-dom-server.production.min.js:1:8762)
    at e.read (/Users/v7rulnik/projects/kupibilet/internals/kupibilet.ru/node_modules/react-dom/cjs/react-dom-server.production.min.js:1:8452)
    at Object.T [as renderToString] (/Users/v7rulnik/projects/kupibilet/internals/kupibilet.ru/node_modules/react-dom/cjs/react-dom-server.production.min.js:1:4384)
    at repl:1:13
    at ContextifyScript.Script.runInThisContext (vm.js:44:33)

Answer 23 · 2017-07-27T02:55:34.000Z

The server renderer doesn't yet support returning arrays and strings from components.

Does this mean doesn't support them at all? or just as the root component i.e. ssr(<somecom /<<otherComp /<)?

This could be really bad if it does break it as array returns are life, but so is SSR

Answer 24 · 2017-07-27T02:55:54.000Z

Our large application ran perfectly except for our unit tests that depend on enzyme. This looks like our biggest blocker at this point.

Flarnie and I spoke with Leland about Enzyme this afternoon. Seems like it's in a good spot to be 16-compatible by or before the 16.0 release and we'll be staying in touch about it during the beta.

Answer 25 · 2017-07-27T03:14:54.000Z

The server renderer has been completely rewritten, and now offers a streaming mode

Is the streaming mode specific to Node.js (ie. does it use APIs only available in Node), or could it work in other environments too (for example, for people using ReactJS.NET, react-rails or React in Java)?

Answer 26 · 2017-07-27T03:17:29.000Z

This is an error I hit in a moderately sized app.

It points to this code:

If I open the Object.renderPortal frame it looks like it's in the react-modal library, these lines exactly.

At the very top of that file is does const renderSubtreeIntoContainer = ReactDOM.unstable_renderSubtreeIntoContainer; so this is an unstable API. I can look more into this tomorrow because it very well might be a false positive. I did update both react and react-dom to 16.0.0-beta.1.

I will look more into this tomorrow and see if I can provide more details.

Great work y'all! ❤️

Answer 27 · 2017-07-27T03:21:48.000Z

@jlongster The code in your screenshot isn't 16 beta 1, but some of the stack frames you cited are. You must have two copies of react-dom, one new and one old. npm ls might help you find why.

Answer 28 · 2017-07-27T03:31:53.000Z

Ah ok, thanks! I will check tomorrow, not at my computer anymore

Answer 29 · 2017-07-27T03:48:48.000Z

Maybe @aickin can comment on the feasibility of integrating a caching solution directly into the server renderer?

@dmitrif While I think it's certainly conceivable to implement a caching solution in the server renderer, I don't think it's amenable to monkey patching; the renderer is basically all just in one file. If it's really important to you, I'd fork the code (and hopefully consider contributing back!).

It's also worth noting that in some preliminary tests I did, the 16 renderer is 2-2.5x faster than the 15 renderer, so it's possible that you may not have as much of a need for caching.

Answer 30 · 2017-07-27T03:57:16.000Z

Does this mean doesn't support them at all? or just as the root component i.e. ssr(<somecom /<<otherComp /<)?

@falconmick I believe it doesn't support them anywhere in the tree right now, but it's a "known issue", which I believe means it should get fixed before release. (Anyone from core team, please feel free to correct me!)

Answer 31 · 2017-07-27T03:59:18.000Z

@Daniel15 I think /server is browser-only APIs and /node-stream is browser+node APIs. The naming of these entry points isn't great and may change before final.

Answer 32 · 2017-07-27T03:59:44.000Z

@aickin @falconmick That's the plan! If anyone wants to work on adding that, we'd happily review a PR.

Answer 33 · 2017-07-27T04:05:17.000Z

Is the streaming mode specific to Node.js (ie. does it use APIs only available in Node), or could it work in other environments too (for example, for people using ReactJS.NET, react-rails or React in Java)?

@Daniel15 The streaming renderer does indeed depend on the Readable API in Node. For more info on the streaming API, check out its documentation.

However, I should note that the underlying code for the renderer is a function that will output N bytes at a time, which you could in theory call from just about any stream API. If you want to see code that uses this function, check out the implementation of ReactMarkupReadableStream. This is a proceed-at-your-own-risk kind of thing, though, because the internal class (ReactPartialRenderer) is not a supported API and could change at any moment.

Answer 34 · 2017-07-27T04:16:03.000Z

@7rulnik Great bug, and I'm able to repro on my machine. I've filed it as #10299. Thanks!

Answer 35 · 2017-07-27T04:29:06.000Z

Can I try out React 16 beta with fiber in a react-native project?

Answer 36 · 2017-07-27T04:37:31.000Z

@aakashbapna Instructions for that will be coming soon. Currently I think you'd have to build from source to try it.

Answer 37 · 2017-07-27T06:10:26.000Z

Also seeing @7rulnik's issue #10294 (comment) regarding style on the server in production mode.

(re is not a function)

Answer 38 · 2017-07-27T09:19:35.000Z

Hi! i opened an issue on react-virtualized repo #762

Thanks!

Answer 39 · 2017-07-27T09:20:54.000Z

Also seeing @7rulnik's issue #10294 (comment) regarding style on the server in production mode.

Fixed by #10300. Will go out in next beta after we catch a few more issues.

I believe it doesn't support them anywhere in the tree right now, but it's a "known issue", which I believe means it should get fixed before release.

There’s an open PR for this too: #10221

Can I try out React 16 beta with fiber in a react-native project?

Not yet. Please see the above post:

React Native follows a different release cycle and will update to the beta in a future release. (It's already using an alpha release but not yet using Fiber.)

Answer 40 · 2017-07-27T13:26:44.000Z

We've got some unit tests where we test that the data returned from a react-redux mapStateToProps and mapDispatchToProps conforms to the propTypes of the underlying component.

We do this through the use of react/lib/ReactPropTypesSecret so we can use the PropTypes testing function directly. Is there anything we could do moving forwards to replicate this functionality?

Answer 41 · 2017-07-27T13:27:20.000Z

Any docs on this new react-dom/node-stream?
Edit:
https://github.com/facebook/react/blob/master/docs/docs/reference-react-dom-node-stream.md

Answer 42 · 2017-07-27T13:38:52.000Z

@TeaSeaLancs

We've got some unit tests where we test that the data returned from a react-redux mapStateToProps and mapDispatchToProps conforms to the propTypes of the underlying component.

You can do something like:

React.createElement(YourComponent, propsYouWantToTestWith);

This will trigger PropTypes validation. If there is a failure, it will use console.error() to output the warning. You can override console.error() in tests, and throw on any unexpected errors.

Answer 43 · 2017-07-27T13:46:34.000Z

Fair enough but having to stub/monkey patch something as fundamental as console.error() leaves a bit of a sour taste in the mouth :\

Answer 44 · 2017-07-27T13:54:08.000Z

Now that I think of it, actually it’s not necessary. PropTypes provides a first-class API for running checks. In fact it’s what React uses.

If you look at the warning message that you get when you call them directly, it says:

Calling PropTypes validators directly is not supported by the prop-types package. Use PropTypes.checkPropTypes() to call them.

As mentioned in prop-types README:

If you absolutely need to trigger the validation manually, call PropTypes.checkPropTypes(). Unlike the validators themselves, this function is safe to call in production, as it will be replaced by an empty function:

// Works with standalone PropTypes
PropTypes.checkPropTypes(MyComponent.propTypes, props, 'prop', 'MyComponent');

Hope this helps!

Answer 45 · 2017-07-27T13:57:02.000Z

@spicyj You were right, I had two versions of React. I made sure everything was on next and it's mostly working.

I still hit an error in one case. I use the react-modal library, and when try to close the modal it errors:

This is the line of code where the error is happening. For some reason it looks like this.portal is null.

Unfortunately, I created a small test case to try to reproduce, but that library works fine independently of my app. I don't know if this is 16's fault or not, but it definitely worked with 15. Sorry I can't reproduce in a small test case, but wanted to report this bug in case it gives more context into a possible bug.

Answer 46 · 2017-07-27T13:58:50.000Z

@gaearon ... when did that get introduced? I swear I never saw that message :P

Answer 47 · 2017-07-27T13:59:30.000Z

@TeaSeaLancs I think during 15.5 or about that. You’re right it didn’t always exist, sorry!

Answer 48 · 2017-07-27T14:00:30.000Z

Fair enough, we started on 15.2 originally.

Answer 49 · 2017-07-27T14:01:38.000Z

@jlongster Any chance you could put breakpoints around this.portal assignments and figure out why this.portal becomes null?

Answer 50 · 2017-07-27T14:09:30.000Z

All of my react/lib/* errors are from react-addons-* packages trying to use them. Are there beta releases of the addons libs?

Answer 51 · 2017-07-27T14:09:40.000Z

@gaearon Here's what I found. The renderSubtreeIntoContainer function that react-modal is calling here returns null. I stepped into that call and found where it is returning null. It's right here:

Here's the stack trace:

If it helps, here's what containerFiber is that it is checking to see if it has a child property:

So basically renderSubtreeIntoContainer is returning DOMRenderer.getPublicRootInstance(root) which returns null for some reason. I hope this isn't a false positive and I'm wasting your time...

Answer 52 · 2017-07-27T14:10:03.000Z

@gaearon, @jlongster I bet it's caused by the changes to unstable_renderSubtreeIntoContainer (#5990, #9808)
Oh, to slow. ;-)

Answer 53 · 2017-07-27T14:10:39.000Z

@wbeard

All of my react/lib/* problems are from react-addons-* packages trying to use them. Are there beta releases of the addons libs?

All react-addons-* packages that are compatible with React 16 already have versions that don’t use internals (I think it’s 15.6.x). Try to update them. Some addons are incompatible with React 16 (e.g. -perf). You’d need to stop using them.

Answer 54 · 2017-07-27T14:12:45.000Z

@jochenberger I don’t think those issues are related because this code has been rewritten from scratch. So past issues probably won’t apply.

@jlongster Thanks, this is useful. Let me take a look and I’ll probably have to ask for more info and screenshots.

I want to mention that longer term, unstable_renderIntoContainer is going away, and unstable_createPortal takes its place. It solves the timing issues. But I’d like to understand if what you encounter is a bug or not. It’s not clear to me yet.

Answer 55 · 2017-07-27T14:13:52.000Z

@gaearon If think this is an actual bug and ever want to even remotely control my machine to take a look, I'd be happy to let you :)

Answer 56 · 2017-07-27T14:13:57.000Z

@gaearon Thanks! Are those addons temporarily incompatible or will they be deprecated?

Answer 57 · 2017-07-27T14:14:57.000Z

@wbeard Which addons specifically? There’s some info on #9207 but happy to answer more specific questions in this thread.

@jlongster Yes, that would be great. Are you free now? You can hop into my DMs.

Answer 58 · 2017-07-27T14:17:09.000Z

@gaearon Sorry, should have been more precise. I was asking about -perf. I'm using the following addons:

"react-addons-create-fragment": "15.6.x",
"react-addons-css-transition-group": "15.6.x",
"react-addons-perf": "15.4.2",
"react-addons-pure-render-mixin": "15.6.x",
"react-addons-shallow-compare": "15.6.x",

I'll read over that issue to get me up to speed and see what needs to be cut out for now.

Answer 59 · 2017-07-27T14:18:17.000Z

Yes, you’d have to stop using -perf for now. The rest should keep working. We don’t have a plan for -perf yet, and likely won’t have it until some time during 16.x.

Answer 60 · 2017-07-27T14:19:33.000Z

No worries, it's being used in a dev-only middleware, so we can come up with a different strategy most likely using marks.

Answer 61 · 2017-07-27T14:20:45.000Z

@wbeard FWIW React 16 beta always emits performance.mark() and performance.measure() calls in DEV so you can capture those using Performance Observer API. See this proof of concept.

Answer 62 · 2017-07-27T14:26:58.000Z

@gaearon Do you think that behavior will continue to be in future releases of 16?

Answer 63 · 2017-07-27T14:27:13.000Z

@wbeard What behavior?

Answer 64 · 2017-07-27T14:28:13.000Z

@gaearon

always emits performance.mark() and performance.measure() calls in DEV

Answer 65 · 2017-07-27T14:29:45.000Z

I don’t know. We’ll start doing this for now. If people get inconvenienced we can add an opt-out API. But I’d like to try to keep it on by default.

Answer 66 · 2017-07-27T14:58:43.000Z

@zyzski You can open React DevTools and use search to find <navigation> in it. Indeed, there is no such HTML element. (Maybe they intended to use <nav>.)

Answer 67 · 2017-07-27T15:05:04.000Z

@lestad

Ex.: I want to pass change event to parent when toggle button.

What’t the advantage of using SyntheticEvent here? In fact I would recommend to not pass event objects around because they get pooled. Read the data early, and pass a plain object representing the data you care about.

Answer 68 · 2017-07-27T17:07:57.000Z

Update: Just published 16.0.0-beta.2 which fixes the SSR crash.
Please give SSR another test round!

Answer 69 · 2017-07-27T17:28:46.000Z

Is it true that I can not use react-hot-loader in the latest version (1.3.x) with React 16?
When I do I get Module not found: Error: Can't resolve 'react/lib/ReactMount' in 'home/flaukel/development/...' all over the place.
Obviously react-hot-loader uses the deprecated react/lib/* references.
It's working with the v3 beta though. Just wondering.

Answer 70 · 2017-07-27T17:31:20.000Z

@coldi Yes, RHL 1.x depends on internal modules that don’t exist anymore.

Answer 71 · 2017-07-27T18:30:02.000Z

@gaearon What if I want emulate event?

Answer 72 · 2017-07-27T18:46:27.000Z

@lestad is there any specific reason you want to emulate an event? You could always just build a mock event object with the fields you intend to consume.

Answer 73 · 2017-07-27T19:10:06.000Z

We Reelgood recently switched over to React 16 (beta 2) in prod and have yet to experience any irregularities as of yet; Awesome work react team!

Answer 74 · 2017-07-27T19:23:22.000Z

I'm looking forward to making the switch! awesome job

Answer 75 · 2017-07-27T19:24:30.000Z

Note there are still some known issues at the top 😉

Answer 76 · 2017-07-28T09:47:06.000Z

Been testing 16 and has been working well for us. The main issue now is the lack of community solutions / documentation around some of the warnings being displayed. The warnings don't provide enough information to understand why they are occurring/ how to solve them. I've posted the warning I encountered on stackoverflow here Did not expect server HTML to contain <div>

Answer 77 · 2017-07-28T12:01:01.000Z

If you support older browsers and devices which may not yet provide these natively (eg <IE11)

You mean <=IE11

Answer 78 · 2017-07-28T13:59:12.000Z

@davidfurlong It means your server rendered HTML is not matching markup on the client. Can you create a small reproducing example so we can look at why?

Answer 79 · 2017-07-28T14:14:08.000Z

@gaearon ah so this is an upgrade from the similar errors in react 15 which gave the first two places in the stringify-ed client and server renders where they differed. I've found these errors in the past to be insufficient in debugging where in the code the renders differ, at one point I even modified the local compiled react source code to not truncate these diffs.

Sometimes it seems necessary for the client and server renders to differ as some libraries don't support SSR and I thus wrap them in a HOC which renders null on the server. (Thus I expect this to be the expected behaviour and not a bug)

Answer 80 · 2017-07-28T14:39:25.000Z

@davidfurlong There is an issue for better SSR validation warnings in #10085. Might not make it into final 16 release.

some libraries don't support SSR

You can also not render them on first render. e.g.

componentDidMount() {
  this.setState({ hasMounted: true })
}

render() {
  return (
    <div>
      Hello
      {this.state.hasMounted && <Datepicker />
    </div>
  )
}

It’s not ideal but works around the problem.

Answer 81 · 2017-07-28T14:42:16.000Z

If you render null on server you need to do the same on initial render in client. You could use e.g. redux-mediaquery to manage that.

…

On Fri, Jul 28, 2017, 4:15 PM David Furlong ***@***.***> wrote: @gaearon <https://github.com/gaearon> ah so this is an upgrade from the react 15 similar errors which gave the first two places in the stringify-ed client and server renders where they differed. I've found these errors in the past to be insufficient in debugging where in the code the renders differ, even at one point modifying the local compiled react source code to not truncate these diffs. Sometimes it seems necessary for the client and server renders to differ as some libraries don't support SSR and I thus wrap them in a HOC which renders null on the server. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#10294 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADWlsYUF8JiOPYmPDgAKQ8GYFFYOUC4ks5sSez_gaJpZM4Oka5I> .

Answer 82 · 2017-07-28T14:48:37.000Z

If you support older browsers and devices which may not yet provide these natively (eg <IE11)

You mean <=IE11

@graingert IE 11 has basic support for Map and Set and should not require polyfillying for React's purposes. If this is incorrect let me know and I can update the instructions at the top.

Answer 83 · 2017-07-28T14:49:15.000Z

anyone else seen this one? when using reactstraps popovers?

Answer 84 · 2017-07-28T14:51:38.000Z

@th3fallen Please provide a small example reproducing this.

Answer 85 · 2017-07-28T14:53:23.000Z

@gaearon i'll do one better, i'll make a staging branch of my app with it. give me ~10m

Answer 86 · 2017-07-28T14:57:58.000Z

@th3fallen If I look at the stack trace it shows both files from react-dom@15 and react-dom@16. That’s what’s causing the issue. Make sure you only have one react and one react-dom (and that they’re both 16).

Answer 87 · 2017-07-28T15:02:09.000Z

@gaearon meh, i'll try to clean those out. is there per chance a super easy way im not aware of?

Answer 88 · 2017-07-28T15:18:53.000Z

@th3fallen just rm your node_modules and install again, then check with `npm ls react`

…

On Fri, Jul 28, 2017, 5:03 PM Clark Tomlinson ***@***.***> wrote: @gaearon <https://github.com/gaearon> meh, i'll try to clean those out. is there per chance a super easy way im not aware of? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#10294 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADWlu_YfQ5uHIaQciqdleK46yAbmQvaks5sSfhUgaJpZM4Oka5I> .

Answer 89 · 2017-07-28T15:20:18.000Z

And npm ls react-dom too.

Answer 90 · 2017-07-28T15:23:12.000Z

actually it's a package im using that requires react directly making a PR to move them to peer deps, thanks for the pointers though guys.

Answer 91 · 2017-07-28T17:39:06.000Z

I am either confused or intimidated by the bullet point that states "It is not safe to re-render into a container that was modified by something other than React. This worked previously in some cases but was never supported. Now an explicit error will be thrown". Does this mean that you guys are actively allocating resources to validate that the DOM has not been modified by something like a jQuery plugin?

Answer 92 · 2017-07-28T17:48:30.000Z

@wiredearp This means if you have something like a browser extension that mutates the DOM outside of React's awareness- a case React can't function correctly in- React now explicitly ~~errors rather than trying (and possibly failing) to work.~~ warns about potentially not being able to function correctly.

Answer 93 · 2017-07-28T17:52:47.000Z

@bvaughn sounds like people will need to defend themselves from jQuery and extensions with Shadow DOM or similar?

Answer 94 · 2017-07-28T17:55:09.000Z

@bvaughn @wiredearp assuming that bullet point refers to #10210 it's actually just a warning, not an error. It also specifically looks at whether the root element (rendered by React) of the container (what you pass to ReactDOM.render) is the same. For example, if you have:

var node = document.getElementById('app');
ReactDOM.render(<App />, node);

and you mutated the container element:

node.innerHTML = "<div>Mutated!</div>"

React would warn. This shouldn't affect manual DOM mutations that you may be doing at leaf nodes. Here's an example of that.

Answer 95 · 2017-07-28T17:56:08.000Z

On that note, @bvaughn that example also doesn't process the second ReactDOM.render call, even though we only issue a warning. Should it be erroring or processing the update?

Answer 96 · 2017-07-28T18:09:48.000Z

You're right @aweary. I thought we were throwing an error rather than just warning.

cc @flarnie who has more context here than me.

Answer 97 · 2017-07-28T18:16:47.000Z

@aweary we have had a fair amount of discussion on this. I agree that the behavior should either throw an error or succeed in a way that users expect.

We did reach agreement that adding a warning was better than leaving it as a silent failure. I'll add an item for revisiting this.

Answer 98 · 2017-07-29T07:52:43.000Z

I've observed in an application that a ReactDOM.render called from componentDidMount now can return null instead of the reference to the component. If this is an expected change I think it should be presented in release notes.

Answer 99 · 2017-07-29T09:59:43.000Z

Just to make sure I'm on the safe side here: If I render an empty <div /> using React (a leaf node) and then populate the div using a non-React plugin, is that still supported?