Update for React 0.14.x

[mxdubois]

Hey,

I know it's a bit early, as React 0.14.x is still in beta, but sometime soon it'd be good to get a branch going with 0.14.x support.

I'm seeing these warnings:

Warning: `require("react").findDOMNode` is deprecated. Please use `require("react-dom").findDOMNode` instead.

Everything else seems to be fine, though.

[bruderstein]

Could this be done with a one-time check? Something like

var React = require('react');

var findDOMNode = React.findDOMNode;
if (React.version.split('.')[1] >= '14') {
   findDOMNode = require('react-dom').findDOMNode;
}

I've not tried this (not sure if findDOMNode needs to be bound or not, for example), but if this is the only issue, it might be worth trying it, then we can stick with one npm version that supports 0.13 & 0.14.

Are there any other components supporting both 0.13 and 0.14?

[mxdubois]

That seems reasonable to me. I might check the major version number too, just to be future proof.

[bruderstein]

🎉 v1.0 support 🎉 !

Seriously though, I suspect supporting more than two versions of react is currently extremely difficult - between two versions everything should still work, just possibly with deprecation warnings, between 3 versions, all bets are off!

Be good to know if this kinda logic works in practice though.

[JedWatson]

@mxdubois I'd prefer not to branch until we're ready to commit, long-lived branches tend to create more problems than they're worth, and any project overhead cuts into effort that could be spent on better things.

Unfortunately, require('react-dom') would blow things up with Browserify because browserify doesn't evaluate conditions (it can't, really) before bundling modules. So while @bruderstein's workaround would work in a node environment, it'll be a nightmare for packagers :(

I suspect supporting more than two versions of react is currently extremely difficult

This is correct, and we'll probably want to keep react-select compatible with 0.13 for a while, since there are major changes coming to context (among other things) that will make upgrading a patchy experience until support is consistent across major community packages and developers have had a chance to fix for them.

Not sure if we'll be able to do anything about those warnings in the meantime, as much as I'd really like to 😕

[mik01aj]

I tried it with React 0.14.0-beta3 and apart from the warning, I get an error:

This is the line of code that causes this (most recent piece of your code in stacktrace):

[JedWatson]

@mik01aj that's often the error you get when you've got two instances of React loaded in your page. Maybe check for that? Something might be depending on 0.13 and causing problems.

[mik01aj]

@JedWatson you are right! 😮 I have no idea how you guessed it...

[JedWatson]

Only seeing that like a million times in various issues. The first few, it took a lot more effort to work out 😛

[mik01aj]

And now I know why. The other React version comes from node_modules/react-select/node_modules/react/lib/React.js, and it was installed there by npm because it couldn't satisfy the peerDependency of react@>=0.13.3 (I have React 0.14.0-beta3 in the main package).

[mik01aj]

Ah peerDependencies... Is there anything we can do to prevent this installation of unneeded, second instance of React? (e.g. require version >=0.13 <0.15 or so). Imho React 0.14, despite being in beta, can be considered pretty stable.

[JedWatson]

I loved that tweet.

I've added a condition to package.json that allows for it (beta releases aren't covered by the usual syntax with semver) and am about to release a new version, just merging PRs that are ready to go & writing up a changelog now. If you're impatient, you can pull from master and it should work.

[mik01aj]

It still installs [email protected] because react-input-autosize, which is your dependency, also has a peer dependency of react@>=0.13.0. :(

[JedWatson]

Yup. I just published a new version of that too - v0.5.1. try again?

[mik01aj]

Works now! Thanks!

(btw, I didn't notice that the react-input-autosize is yours as well, sorry for the 2nd ticket).

[JedWatson]

No worries. I needed it for react-select, and it seemed like it was worth publishing on its own 😀

I've just released a new version of react-select that should support react 0.14, let me know how you go.

[newoga]

FYI, based on my understanding, React.findDOMNode() will stop working starting in [email protected] which according to facebook/react#4600 should be coming out soon. Also, if I'm not mistaken, it seems like all of react-select's uses of findDOMNode() can removed as of [email protected] since this.refs.{refValue} now returns the actual dom node.

This is described here: https://facebook.github.io/react/blog/2015/10/07/react-v0.14.html#dom-node-refs

I guess one approach is that [email protected] can support [email protected]. and [email protected] with warnings. And then [email protected] or something of that sort could be released to support [email protected] without warnings and [email protected].

For [email protected], I'd imagine that we shouldn't even need to import react-dom. We should only need to make the following changes:

var itemNode = React.findDOMNode(this.refs.item); // old
var itemNode = this.refs.item; // new

Not having a dependency on react-dom (or the DOM in general) would be a good win the for the project I think and could warrant a new minor release.

[damassi]

There is also the ability to bundle with Webpack if Browserify is causing issues. I'd be willing to help if you need the resources. The react-dom warning is driving me mad since they now bold it in red.

[JedWatson]

Just realised I didn't close this when 0.7 was released with React 0.14 support. Doing that now :)