-
Notifications
You must be signed in to change notification settings - Fork 72
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
React 15 prep #9
Conversation
} | ||
|
||
return <noscript />; | ||
})(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
easier thing to do would be:
function Empty() {
return null;
}
<Empty/>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah that's much better. I'll update.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So it turns out that rendering null
from a stateless component is only allowed in React 15 (issue). I can do something like this:
class Empty extends React.Component {
render() {
return null;
}
}
But because it's a pure component class, it's getting transformed by the babel-plugin-react-pure-components
back to a stateless function before the tests run. We could just force it with something like this:
class Empty extends React.Component {
notPure() {}
render() {
return null;
}
}
Not sure I love that, but it does work. What do you think?
Just went through a bunch of hoops to try this out on project currently in dev, and have found no issues so far. 👍 |
Any updates on this? Would love to update my project to React 15, and this is the only thing preventing me from doing so. Let me know if there's anything I can do to help. Thanks! |
As far as I could tell the only real production issue in React 15 with this lib was the Trying to support both React 14 & 15 in the tests was where it got confusing, but I'm not sure it really makes sense to do that. Unless we set up the test cases to actually run multiple versions of React, we'd only ever be testing one version. It might just be easier to:
I'm happy to make more updates, just not sure what direction to go. Thoughts? |
Thanks for the update @npbee, and yeah, the |
Just got here after banging my head against the error for a while. Glad to see that this is moving fast! Good work everyone! |
How about we start with cherry-picking 17f49ca into master since that's seems to be useless code anyway, regardless of React version? |
This is a leftover from a previous version of the library and doesn't look to be needed. Leaving it in place will cause a runtime error during development with React v15 because `ref` is always defined on `props` as a "special" prop. Trying to delete it will throw an error because props are frozen with `Object.freeze`
Moving React to a peer dependency plus a separate dev dependency for testing seems to be the current standard practice for React libraries. It allows for testing a specific version of React while still outwardly supporting multiple versions. Also, it helps to alleviate the multiple React problems with npm 3 users.
Ok I tried to cleaned up a bit and do what seemed to be the minimal amount of changes to get this working:
|
Adds in a couple of small changes to prepare for React 15 support.
ref
inprops
.Fixes #8