Skip to content

async-safe, static lifecycle hooks #6

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.

Sign up for GitHub

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

Merged
acdlite merged 22 commits into from
Jan 19, 2018
Merged

async-safe, static lifecycle hooks #6

Changes from 1 commit
Commits
Show all changes
22 commits
Select commit Hold shift + click to select a range
9818f57
Initial proposal for async-friendly, static lifecycle hooks
bvaughn Dec 8, 2017
839547f
Added a note about the prefix
bvaughn Dec 8, 2017
b7189cc
Made deprecation/rename clearer
bvaughn Dec 8, 2017
aad6845
Hopefully clarified the computeMemoizeData() placeholder example
bvaughn Dec 8, 2017
99988da
Renamed example method for improved clarity
bvaughn Dec 9, 2017
4a34d25
Added note about aEL being unsafe in cWM
bvaughn Dec 9, 2017
902d4b3
Fixed typo
bvaughn Dec 9, 2017
3df7ce6
Fixing typo
bvaughn Dec 9, 2017
1864c93
Removed Facebook-specific terminology
bvaughn Dec 9, 2017
428758b
Tweaked wording for clarity
bvaughn Dec 9, 2017
cfcb7e8
Reorganization (part 1, more to come)
bvaughn Dec 9, 2017
536084d
Added some more focused examples
bvaughn Dec 9, 2017
a1431a4
Added a comment about calling setState on a possibly unmounted component
bvaughn Dec 9, 2017
3c6132e
Cancel async request on unmount in example
bvaughn Dec 9, 2017
4425dbe
Tweaking examples based on Dan's feedback
bvaughn Dec 9, 2017
67272ce
Renamed deriveStateFromProps to getDerivedStateFromNextProps
bvaughn Dec 13, 2017
c7f6728
Renamed prefetch to optimisticallyPrepareToRender
bvaughn Dec 13, 2017
bb2d246
Added `render` to a list
bvaughn Dec 14, 2017
8618f70
Removed static optimisticallyPrepareToRender() in favor of render()
bvaughn Dec 19, 2017
8f6c20e
Renamed getDerivedStateFromNextProps to getDerivedStateFromProps
bvaughn Jan 18, 2018
e05e317
Updated when getDerivedStateFromProps is called and what its argument…
bvaughn Jan 18, 2018
7042a2a
Renamed unsafe_* to UNSAFE_*
bvaughn Jan 18, 2018
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
Hopefully clarified the computeMemoizeData() placeholder example
  • Loading branch information
@bvaughn
bvaughn committed Dec 8, 2017
commit aad6845560c562b23de416dd37b4f34aa0bf2472
10 changes: 6 additions & 4 deletions text/0000-static-lifecycle-methods.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -33,7 +33,7 @@ class ExampleComponent extends React.Component {

addExternalEventListeners();
Copy link

@aickin aickin Dec 8, 2017

Choose a reason for hiding this comment

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

Adding event listeners in componentWillMount is a bug, right? I know that it would make SSR fail (since there's no DOM), and it seems like you say it's a problem in the Common Problems section. If that's right, a comment to that effect would be super helpful!

Copy link
Collaborator

@sebmarkbage sebmarkbage Dec 9, 2017

Choose a reason for hiding this comment

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

Flux stores are external event listeners that don't need a DOM, but also SSR alone is not necessarily that common. Especially for long tail.

Copy link

@aickin aickin Dec 9, 2017

Choose a reason for hiding this comment

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

Thanks, that's helpful context, but my question here is whether or not this line is currently considered a bug. It sounds like this document is saying yes, it is, although I'm not entirely sure. If so, I think a comment would help understanding. Does that make sense?

Copy link
Collaborator Author

@bvaughn bvaughn Dec 9, 2017

Choose a reason for hiding this comment

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

Yeah. This is not a good pattern. (I listed it below as a common problem we see.) I show it here only to show where it should be done instead. I've added an inline comment to this part of the example though to make it clear that it's not a pattern we recommend. 😄


computeMemoizeData(nextProps, nextState);
this._computeMemoizeData(nextProps);
Copy link

@aickin aickin Dec 8, 2017 •
edited
Loading

Choose a reason for hiding this comment

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

Is nextProps defined here? I may just be missing it, but I don't see where it would be defined.

Copy link
Collaborator Author

@bvaughn bvaughn Dec 9, 2017

Choose a reason for hiding this comment

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

Whoops. This was a typo. Will fix.

}

componentWillReceiveProps(nextProps) {
Expand All @@ -57,7 +57,7 @@ class ExampleComponent extends React.Component {
nextProps.onChange(nextState.someStatefulValue);
}

computeMemoizeData(nextProps, nextState);
this._computeMemoizeData(nextProps);
}

render() {
Expand Down Expand Up @@ -127,8 +127,10 @@ class ExampleComponent extends React.Component {

render() {
// Memoization that doesn't go in state can be done in render.
// It should be idempotent and have no external side effects though.
computeMemoizeData(this.props, this.state);
// It should be idempotent and have no external side effects or mutations.
// Examples include incrementing unique ids,
// Lazily calculating and caching values, etc.
this._computeMemoizeData(this.props);

if (this.state.externalData === null) {
return <div>Loading...</div>;
Expand Down