-
Notifications
You must be signed in to change notification settings - Fork 2k
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
Framework: Upgrade to React 0.14 #1498
Conversation
Wow this is massive, thanks for taking on this issue! I took a quick spin of the branch and found a minor issue in infinite-list which I pushed to the branch. Feel free to squash that in later. 👍 Everything else I tested worked well, plans, editor, settings etc, but since this whole changeset is so large, it'd be good to have a lot more 👀 on this. The console was pretty chatty with warnings, but we can tackle those in future PRs. For anyone else taking a look I would recommend taking a closer look at any places where we replaced getDOMNode() with the bare react instance, instead of a DOM node. In most cases this is fine, but we should double check that each react instance has those node properties. |
@@ -139,7 +140,7 @@ var NavTabs = React.createClass( { | |||
return; | |||
} | |||
|
|||
navGroupWidth = this.refs.navGroup.getDOMNode().offsetWidth; | |||
navGroupWidth = this.refs.navGroup.offsetWidth; |
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.
Here we use this.refs.navGroup.offesetWidth
and above we use ReactDom.findDOMNode( this.refs[ 'tab-' + index ] ).offsetWidth
. It seems to me that one of these is incorrect or at least redundant? (Or maybe not since one is a React component and the other is a DOM component?)
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.
(Or maybe not since one is a React component and the other is a DOM component?)
This is correct. When the ref is applied to a DOM component (in this case, a div
), the ref returns the DOM node directly, whereas in the case where it is a React element (in the above case, a <SectionTab />
), we still must use ReactDom.findDOMNode
if we want access to its rendered node.
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.
Cool. That makes sense now.
Looks good from a code point of view! 95% of the changes are just replacing |
8f8d229
to
03ded7e
Compare
@aduth out of curiosity, did you do this with the |
Functional testing looks good |
I kinda wish I had known of this earlier (though I'm not sure how well this script would work with the additional imports required?). This was entirely by hand, with some help from mass file search. I really appreciate everyone's help with reviews. This is a big one. I'll hope to merge on Monday after another round of rebase + search. Already ran into two separate merge conflicts on Friday, so really don't want to let this one linger too long. |
There's another |
@ockham : Good catch. It's my understanding that nested |
@@ -1,6 +1,7 @@ | |||
/** | |||
* External dependencies | |||
*/ | |||
import ReactDom from 'react-dom'; |
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.
In the future we could even shorten it to:
import { render } from 'react-dom';
...
render( ... );
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.
In the future we could even shorten it to:
Worth discussing, sure. Sometimes I worry that the brevity of it loses important context, i.e. in this case, not as clear that it's using React's render and not some local helper function I've declared.
eae26a4
to
3b4772f
Compare
r-dom is not used and should be removed
We should seek to eliminate this component altogether. The only hold-up now that React 0.14 has introduced timeouts is to remove dependence on Dialog `onClosed`, which is only used by the Reader in unmounting the article component after close.
Required in react-redux when using React 0.14
3b4772f
to
b1f1e74
Compare
Framework: Upgrade to React 0.14
Worth pointing out that the changes here did not capture all instances of using a |
This pull request seeks to upgrade Calypso from React 0.13.3 to React 0.14.3. This requires a significant number of changes, particularly related to the split between
react
andreact-dom
packages (see full change log).The upgrade results in many warnings during testing and development. These include advisements to use
react-addons-
packages in place ofreact/addons
and against rendering to thedocument.body
element (common in tests). The purpose of this pull request is not to resolve these warnings and assumes that they'll be addressed separately.However, warnings on use of
getDOMNode
were included in this pull request, as they are pervasive enough to be considered obnoxious in using the application in development environments. All instances ofgetDOMNode
have been replaced with directref
usage for DOM elements (since aref
is the DOM node reference in React 0.14) orReact.findDOMNode
(when the element is a React component or references thethis
instance directly).Testing instructions:
Run
make test
from the root directory and verify that all tests pass (with warnings).Ensure that regressions should be found in navigating the application in the browser.
Code verification:
Ensure that no
ReactDOM
methods are used with the baseReact
package.Verify that all removals of
getDOMNode
apply only to DOM elements.