DianaSuvorova / eslint-plugin-react-redux

Enforcing best practices for react-redux

Home Page:https://www.npmjs.com/package/eslint-plugin-react-redux

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

No react-redux errors

gpspake opened this issue · comments

I installed eslint-plugin-react-redux and added to my eslint config but I'm not getting any errors even though I'm breaking a lot of rules. I'm hoping I'm just missing something simple.

Here's where I've added react-redux to my eslint config. I should be getting errors but I'm not.
To reproduce:

git clone https://github.com/gpspake/react-cool-starter.git
cd react-cool-starter
yarn install
yarn lit:js

I notice that if I remove 'react-redux' from the "plugins" I get a bunch of 'definition for rule was not found errors' which at least tells me that the plugin is installed and recognized.

@gpspake , thanks for giving it a try. Your eslint configs seems correct.

Through out the code this plugin assumes that connect function signature looks like connect(whatever)(whatever) (code). while your connect usage looks like connect(whatever) (Home for example) That's why this plugin doesn't pick up any errors .

I can relax the condition to assume that if one has this plugin on and has a connect function call with any signature it is likely a react-redux's connect and run lint rules.

@ljharb , what do you think?

Ok, thanks. That helps. My goal here is actually to refactor this project to use the pattern you're describing so it sounds like the first step is to refactor the connect statements.
I'll leave this open for the further discussion about 'relaxing the condition' you brought up but feel free to close :)

Update: I refactored the user info container to use the mapStateToProps, and mapDispatchToProps convention and I understand your previous comment a little better.
Since compose is being used here, and compose is imported from Redux, perhaps the rule should be modified to account for compose instead of relaxing it completely. Does that sound right?

yes, that is another possibility account for compose - might be a better option.

Just working through the logic here, would we have something like this that would check for compose first; then lint for the alternate connect syntax; otherwise lint for the connect statement.
I'm having a hard time getting the rules to fail, currently.
I haven't written my own eslint rules before so I'm interested in helping if you have any pointers.

@gpspake, thanks for the follow up. I created a PR to relax the connect function definition so it should pick up your case. I am going to wait for few days for any feedback before merging and releasing an update.

Awesome! I'm gonna try it out :D

Hey @gpspake PR was merged, 2.3.0 release should have the change.