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

Use callback state update for updates relying on previous (state, props) #1158

Merged
merged 1 commit into from
Jun 19, 2017

Conversation

youknowriad
Copy link
Contributor

@youknowriad youknowriad commented Jun 13, 2017

Just trying to close #1117 #1118 #1119 #1120 #1121 #1122 #1123 #1124

When state updates rely on previous state or props, we should use callbacks. That's the latest recommendations (setState can be asynchronous). More details in the discussion here #1124

@youknowriad youknowriad added the [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). label Jun 13, 2017
@youknowriad youknowriad self-assigned this Jun 13, 2017
@youknowriad youknowriad force-pushed the update/state-update-as-function branch from 3ffcf8d to 0c2bb45 Compare June 13, 2017 11:37
Copy link
Member

@aduth aduth left a comment

Choose a reason for hiding this comment

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

Still scratching my head as to where the line should be drawn between this being a theoretical issue vs. an actual issue.

( this.state.selectedSuggestionIndex + 1 ) || 0,
this.getMatchingSuggestions().length - 1
( state.selectedSuggestionIndex + 1 ) || 0,
this.getMatchingSuggestions( state, props ).length - 1
Copy link
Member

Choose a reason for hiding this comment

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

This is an unfortunate a consequence from this sort of change. In general it'd be nice if we could at least create the function signature to include only those relevant to generating its result, not just accepting entire state and props of the instance. In this case it needs a fair few values (suggestions, incompleteTokenValue, value, max), so not sure if it's much of an improvement.

@youknowriad
Copy link
Contributor Author

Anyway, we should make a decision, close all those issues or merge this PR :).
I'm hesitant too.

@BE-Webdesign
Copy link
Contributor

BE-Webdesign commented Jun 13, 2017

Personally I like it, and it only adds two lines of code, which could even be eliminated. I am not overly partial either way, so if we close out the issues, and not merge, not a big deal. I believe this is a best practice now as well, so I lean more towards merging.

For #1124, it actually has made certain aspects of applying formats in the editable less buggy, when I am goofing around trying to break it. The selection stuff gets broken pretty easily still and I haven't had time to look into yet.

tl;dr I approve, but don't take that as a strong reason to merge or anything, I leave the final decision to aduth and yourself, or matias, someone other than me, as I am biased towards thinking this is better.

@youknowriad youknowriad removed the [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). label Jun 14, 2017
@youknowriad
Copy link
Contributor Author

I've been thinking more about this. And I'm starting to lean towards merging this.

Not explored in this PR, but this pattern has a nice side-effect allowing the state changes to be declared (and tested) separately from the component itself. https://medium.freecodecamp.com/functional-setstate-is-the-future-of-react-374f30401b6b#2c7e

Btw, since we're already using Fiber, I think we should comply with its best practices even if this pattern is only needed if we use the async mode of Fiber (which is not enabled yet).

@aduth
Copy link
Member

aduth commented Jun 14, 2017

Okay, I'm not so much opposed to it, but but thinking we should come up with patterns for awkwardness-es like:

https://github.com/WordPress/gutenberg/blob/0c2bb45/components/form-token-field/index.js#L344-L346

In this case, either expecting state and props to be passed consistently, or updating the function signature to reflect the arguments relevant to suggestions being generated.

Aside: getMatchingSuggestions( state = this.state, props = this.props ) { works as an alternative for what exists currently.

@youknowriad
Copy link
Contributor Author

Aside: getMatchingSuggestions( state = this.state, props = this.props ) { works as an alternative for what exists currently.

Yeah, wasn't sure about this. When the default value is resolved.

@aduth
Copy link
Member

aduth commented Jun 14, 2017

Yeah, wasn't sure about this. When the default value is resolved.

Not sure how the spec dictates, but at least Babel transforms it close to what exists in your implementation:

http://babeljs.io/repl/#?babili=false&evaluate=false&lineWrap=false&presets=es2015&targets=&browsers=ie%2011&builtIns=true&debug=false&code=function%20getMatchingSuggestions(%20state%20%3D%20this.state%2C%20props%20%3D%20this.props%20)%20%7B%7D&plugins=transform-runtime

@youknowriad youknowriad force-pushed the update/state-update-as-function branch from 0c2bb45 to 49233c0 Compare June 14, 2017 14:34
@youknowriad
Copy link
Contributor Author

thinking we should come up with patterns

I suspect that this kind of usage won't be so common, but regardless, I don't have any preference here. Happy to use the approach we settle on.

@BE-Webdesign
Copy link
Contributor

BE-Webdesign commented Jun 14, 2017

Side note, #1124 doesn't actually make things better, it was my imagination lol. Not sure what happens but the apply formats is really inconsistent sometimes.

Update: I actually have no idea, because it does seem to work better when the function is used.

@aduth
Copy link
Member

aduth commented Jun 15, 2017

How can we enforce this?

@BE-Webdesign
Copy link
Contributor

How can we enforce this?

Good question. Custom lint? I don't know. I will try and see if I can write a lint for it, never done it before though. I tried finding something that already does this and found nothing.

@youknowriad
Copy link
Contributor Author

Do you agree with merging here as we work on the lint rule separately?

@aduth
Copy link
Member

aduth commented Jun 19, 2017

Sure 😄

@youknowriad youknowriad merged commit 9635125 into master Jun 19, 2017
@youknowriad youknowriad deleted the update/state-update-as-function branch June 19, 2017 13:22
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.

Improper use of setState
3 participants