Skip to content
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

Merged
merged 7 commits into from
Dec 14, 2015
Merged

Framework: Upgrade to React 0.14 #1498

merged 7 commits into from
Dec 14, 2015

Conversation

aduth
Copy link
Contributor

@aduth aduth commented Dec 11, 2015

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 and react-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 of react/addons and against rendering to the document.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 of getDOMNode have been replaced with direct ref usage for DOM elements (since a ref is the DOM node reference in React 0.14) or React.findDOMNode (when the element is a React component or references the this 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 base React package.

Verify that all removals of getDOMNode apply only to DOM elements.

@aduth aduth added Framework [Status] Needs Review The PR is ready for review. This also triggers e2e canary tests and wp-desktop tests automatically. labels Dec 11, 2015
@gwwar
Copy link
Contributor

gwwar commented Dec 11, 2015

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;
Copy link
Member

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?)

Copy link
Contributor Author

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.

Copy link
Member

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.

@sirbrillig
Copy link
Member

Looks good from a code point of view! 95% of the changes are just replacing React with ReactDom or getDOMNode with the direct reference. For those other eyes who look at this, maybe check those places where there were changes that didn't just change modules (I wonder if there's some way to generate a view like that in GH?)

@aduth aduth force-pushed the update/react-0-14 branch from 8f8d229 to 03ded7e Compare December 11, 2015 20:43
@blowery
Copy link
Contributor

blowery commented Dec 12, 2015

@aduth out of curiosity, did you do this with the jscodeshift script or by hand? https://github.com/reactjs/react-codemod/blob/master/README.md

@blowery
Copy link
Contributor

blowery commented Dec 12, 2015

Functional testing looks good

@aduth
Copy link
Contributor Author

aduth commented Dec 12, 2015

@aduth out of curiosity, did you do this with the jscodeshift script or by hand?

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.

@ockham
Copy link
Contributor

ockham commented Dec 14, 2015

There's another package.json that specifies a react dependency in https://github.com/Automattic/wp-calypso/blob/master/client/my-sites/all-sites-icon/package.json#L7, which is currently at 0.12.1. Do we want to upgrade that, or can we just drop it?

@aduth
Copy link
Contributor Author

aduth commented Dec 14, 2015

@ockham : Good catch. It's my understanding that nested package.json aren't considered for their dependencies, but are only used these days to control the entry point of a directory. In which case, I think we can safely remove this file. I'll do a scan over the entire codebase for similar instances.

@@ -1,6 +1,7 @@
/**
* External dependencies
*/
import ReactDom from 'react-dom';
Copy link
Member

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( ... );

Copy link
Contributor Author

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.

@aduth aduth force-pushed the update/react-0-14 branch 2 times, most recently from eae26a4 to 3b4772f Compare December 14, 2015 14:05
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
@aduth aduth force-pushed the update/react-0-14 branch from 3b4772f to b1f1e74 Compare December 14, 2015 14:10
@aduth aduth added [Status] Ready to Merge and removed [Status] Needs Review The PR is ready for review. This also triggers e2e canary tests and wp-desktop tests automatically. labels Dec 14, 2015
aduth added a commit that referenced this pull request Dec 14, 2015
@aduth aduth merged commit a265f8b into master Dec 14, 2015
@aduth aduth deleted the update/react-0-14 branch December 14, 2015 14:19
@aduth
Copy link
Contributor Author

aduth commented Dec 14, 2015

Worth pointing out that the changes here did not capture all instances of using a ref that could have been simplified to not use ReactDom.findDOMNode, but instead leverages findDOMNode overloading which returns the same value if passed a DOM node.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants