Skip to content

Conversation

avaly
Copy link

@avaly avaly commented Aug 5, 2016

[RFC] Adding a new rule to complement the existing no-did-update-set-state.

This rule will look for any occurrences of this.setState and check whether the method it is being called from is also called inside componentDidUpdate.

If this gets a positive feedback I'll also add a doc page for it.

I could see this as an option on the no-did-update-set-state rule, but the logic is more complex than the original rule, so I decided to keep it separate for now.

@avaly avaly force-pushed the no-did-update-set-state-via-methods branch 2 times, most recently from deb7fb5 to c62b0f4 Compare August 5, 2016 13:14
@lencioni
Copy link
Collaborator

lencioni commented Aug 7, 2016

I'm not sure this needs to be a separate rule. It would also be nice if it allowed these function calls as callbacks with an option to disallow, like we do with the disallow-in-func option.

What do other folks think?

@avaly avaly force-pushed the no-did-update-set-state-via-methods branch from c62b0f4 to 9fccdf9 Compare August 22, 2016 15:00
@avaly avaly changed the title [rule] no-did-update-set-state-via-methods no-did-(update|mount)-set-state: disallow-via-methods option Aug 22, 2016
@avaly
Copy link
Author

avaly commented Aug 22, 2016

I've updated my PR to not create a separate rule for this use case. Instead it uses the logic in both no-did-update-set-state and no-did-mount-set-state rules using a new mode disallow-via-methods.

@avaly
Copy link
Author

avaly commented Aug 30, 2016

👍 / 👎 ? Friendly bump!


The following patterns are considered warnings:

```js
Copy link
Collaborator

Choose a reason for hiding this comment

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

nit: these should be jsx

```js
...
"no-did-update-set-state": [<enabled>, <mode>]
"no-did-update-set-state": [<enabled>, <modeInFunctions>, <modeViaMethods>]
Copy link
Collaborator

Choose a reason for hiding this comment

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

It might be a good idea to use an options object for these modes instead of positional arguments.

That would be a breaking change, so perhaps it should be done in a followup PR.

Copy link
Member

Choose a reason for hiding this comment

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

Both could be supported with eslint schemas as semver-minor - ie, a "mode" string, and then otherwise, an options object.

@lencioni
Copy link
Collaborator

lencioni commented Feb 15, 2017 via email

Copy link
Member

@ljharb ljharb left a comment

Choose a reason for hiding this comment

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

This needs a rebase, and it'd be great to use an options object per https://github.com/yannickcr/eslint-plugin-react/pull/742/files#r101368104

@ljharb
Copy link
Member

ljharb commented Oct 10, 2022

I've rebased this, but a few tests are failing.

@ljharb ljharb force-pushed the master branch 3 times, most recently from 069314a to 181c68f Compare November 18, 2022 17:19
@ljharb ljharb force-pushed the master branch 2 times, most recently from 380e32c to 51d342b Compare July 4, 2024 15:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Development

Successfully merging this pull request may close these issues.

4 participants