-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
Replace componentWillReceiveProps with componentDidUpdate in docs and async component #4109
Conversation
|
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. Latest deployment of this branch, based on commit 6bd0001:
|
fa4e50b
to
bde4330
Compare
Thanks for this PR @manvydasu! |
<3 |
Any timeline on getting this merged and releasing a new version? With strict mode on this reports as a console error which winds up polluting the console with library based messaging making it hard to notice actual errors in your app. |
Do we have any plan to release a new version to fix this? |
Please update when this PR will be merged. It seems we can not get rid of the "Warning: Using UNSAFE_componentWillReceiveProps in strict mode is not recommended and may indicate bugs in your code" until this is merged |
This PR would be very useful, please merge it if possible 😄 thanks, guys! |
EDIT: 🎉 I've archived the fork now that we've got some momentum in this repo and Jed is involved again. Sorry for the disturbance! |
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.
Thanks for this PR! As noted below, the work for Async
will probably become redundant soon and the Header
modification needs to be changed. Really appreciate your help!
docs/App/Header.js
Outdated
UNSAFE_componentWillReceiveProps({ location }: HeaderProps) { | ||
componentDidUpdate(prevProps: HeaderProps) { | ||
const valid = ['/', '/home']; | ||
const shouldCollapse = !valid.includes(this.props.location.pathname); | ||
if (location.pathname !== this.props.location.pathname && shouldCollapse) { | ||
const shouldCollapse = !valid.includes(prevProps.location.pathname); | ||
|
||
if (prevProps.location.pathname !== this.props.location.pathname && shouldCollapse) { |
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.
Doing this on update means that the first time you click away from the home page, the transition won't work (which is actually true of the status quo as well).
Instead I would suggest that we call this.setState({ contentHeight: this.content.scrollHeight });
immediately in componentDidMount
and get rid of toggleCollapse
altogether.
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.
You're right. I removed toggleCollapse
alltogether and removed contentHeight
from the state
itself. My suggested approach will get rid of one additional re-render after componentDidMount
and the functionality remains the same.
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.
@Methuselah96 I tested this locally and doesn't seem to impact anything negatively. Any other concerns or can this conversation be resolved?
bde4330
to
d26c2e2
Compare
d26c2e2
to
fff94e7
Compare
It seems a bit sluggish when transitioning between pages. I ran a profiler and it seems that it is noticable. It could also likely be due to these change being applied against v3 as opposed to v4 (perhaps giving some credit to the performance gains from the lifecycle method replacements from @Methuselah96) , but I'll try these changes against v4 and see if the differences flatten out. |
@ebonow |
I just ran it against v4 and it seems negligible. Could just be an environmental difference between running local dev server against production server. One of the changes I noticed that would show up if you rebase is that jsx is now instead imported from
Also, would you be opposed to helping us rid all of the lifecycle method warnings from the current docs? Looks like a few of these components could use a version bump specifically in react-router. Also you will likely want to run the npm |
TLDR: Don't worry about the other dependencies... Putting this here just to document findings... Did some more research. Other dependencies causing warnings which need to be updated in both the package.json, and docs/package.json:
Outside of that are the atlas dependencies, but these also introduce a peer dependency on styled-components:
Started getting react key errors in the console, and we're replacing the documentation in the near future, so not worth putting more time into it. |
Update header.js to use emotion/react jsx render method
Updated file with prettier formatting
Thanks for the PR @manvydasu and the help getting this done everyone, merging now 🙂 |
partial fix for 4094 (Remove UNSAFE methods from docs).
Other UNSAFE methods are removed with #4313