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

Remove unsafe react lifecycle hooks (Fixes #492) #509

Merged
merged 1 commit into from
Feb 19, 2020

Conversation

boxfoot
Copy link
Contributor

@boxfoot boxfoot commented Jan 15, 2020

Removes all use of componentWillMount and componentWillReceive Props

Motivation and Context

As discussed in #492 -- React will be deprecating some of its lifecycle methods in the next major version. https://reactjs.org/blog/2018/03/27/update-on-async-rendering.html

How Has This Been Tested?

All unit tests pass, and all of the examples in the sample site also work as expected.

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

  • My code follows the code style of this project.
  • My change requires a change to the documentation.
  • I have updated the documentation accordingly.
  • I have read the CONTRIBUTING document.

@boxfoot
Copy link
Contributor Author

boxfoot commented Jan 16, 2020

Update: running yarn run site-dev-server (or npm) still doesn't work, but running the command in the script directly does. I've been able to run the dev site and verify that all of the examples continue to work as expected with these changes.

@wcjordan
Copy link
Member

Awesome, thanks for putting this together, and apologies for our delays responding. This looks good to me. @pradeepnschrodinger could you take a look at well?

I have 2 concerns which I think we should explore before approving for merge.

  1. When I tried this w/ the autoscroll example and updated an input some sort of infinite loop happened. Could you investigate and see if that's something we can fix?
  2. Our peer dependencies currently suggest FDT supports React 13 & 14. But I couldn't get the examples to work on those versions (on this PR or master). We should either confirm these changes continue to work on those versions, or schedule them for a future release where we drop support for those versions. @pradeepnschrodinger do you have a suggestion here?

@boxfoot
Copy link
Contributor Author

boxfoot commented Feb 18, 2020

Thanks for the review @wcjordan. I think I've fixed the infinite loop issue. It sounds like the React 13/14 issue is beyond the scope of this PR so I'll leave it to you and @pradeepnschrodinger to weigh in on the right approach there.

@wcjordan
Copy link
Member

Awesome, thank you. Niranjan & I will work out dealing w/ React 13 & 14 and get back to you shortly on merging this.

Copy link
Collaborator

@pradeepnschrodinger pradeepnschrodinger left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me

@@ -125,7 +125,10 @@ class FixedDataTableCell extends React.Component {
return false;
}

componentWillReceiveProps(props) {
componentDidUpdate(prevProps) {
if (prevProps === this.props) return;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this only true when the component gets rerendered due to a state change within itself?
Also can you reformat this to:

if (prevProps === this.props) {
  return;
}

In the long term, can we skip the extra rerender through use of getDerivedStateFromProps ? @wcjordan

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, since getDerivedStateFromProps was added in React v16.3, will this mean we'll deprecate every react version under v16.3.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yuck, we don't want to deprecate support for everything under 16.3. @pradeepnschrodinger could you ticket out the idea of using getDerivedStateFromProps and we can discuss when may make sense to do that on our roadmap?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Created #512

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great, thanks

componentWillReceiveProps(nextProps) {
componentDidUpdate(prevProps) {
// Only react to prop changes - ignore updates due to internal state
if (this.props === prevProps) return;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

reformat to

if (this.props === prevProps) {
  return;
}


this.setState(boundState);
update() {
this.setState(this.getBoundState());
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks. Not sure how this.setState worked in the constructor earlier.

@wcjordan
Copy link
Member

wcjordan commented Feb 19, 2020

@boxfoot could you update the package.json peerDependencies for react & react-dom to require "^15.3.0"?

I've created a v1.0.x branch which will use if we patch anything else to v1.0 and we'll target master for a v1.1 release where we drop support for React 13, 14, & early 15 (FDT has already stopped working with those versions given our use of React.PureComponent...)

@boxfoot
Copy link
Contributor Author

boxfoot commented Feb 19, 2020

@wcjordan should it be ^15.3.0 || ^16.0.0 to allow React 16?

@wcjordan
Copy link
Member

Good call, now that react is using the major version number ^ isn't enough. Let's do ">=15.3.0"

@boxfoot boxfoot force-pushed the master branch 2 times, most recently from 4413526 to d28f9cd Compare February 19, 2020 21:21
@boxfoot
Copy link
Contributor Author

boxfoot commented Feb 19, 2020

All changes committed (and squashed)

@wcjordan wcjordan merged commit a59831d into schrodinger:master Feb 19, 2020
@wcjordan
Copy link
Member

Sweet, thanks. I've merged to mainline and we'll release w/ v1.1.0

@pradeepnschrodinger
Copy link
Collaborator

We've changed few parts seen in this PR as it had led to some bugs with one of our applications. We also believe that it leads to breakages for other users.

See the cause of the bug and explanation, along with the full changes in PR: #523.

@boxfoot
Copy link
Contributor Author

boxfoot commented Apr 8, 2020

Thanks for the update, good to know!

@wcjordan
Copy link
Member

This is now released w/ v1.1.

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

Successfully merging this pull request may close these issues.

None yet

3 participants