Redux-related lint rules?

[markerikson]

Maybe it's worth coming up with our own set of lint rules (no x => x selectors?)

[EskiMojo14]

other previously suggested rules:

• no spreading ...getDefaultMiddleware()
• no state = foo inside immer reducers

[EskiMojo14]

a no no-op selector lint rule seems a little less necessary now it's checked in runtime, but i suppose it would be nice to be done with static code analysis too

[nevnein]

No immediate destructuring of object returned from useSelector

(Btw I was exploring this, but then I noticed eslint is on the verge of releasing a pretty big v9, so I guess I'll wait for that)

[EskiMojo14]

we'd probably want to put reselect related rules under the same plugin as well - we can always offer a "reselect-only" config

some community-made packages we may want to see if we agree with any rules from:

• reselect
• redux-reselect
• reselect-utils
• react-redux
• react-performance ("To improve performance in react redux applications")

[EskiMojo14]

another thing to possibly catch:

const middleware: Middleware =>
  api =>
  next =>
  async (action) => {}

the final function for a middleware should never use the async keyword, because then every dispatch returns a promise.

[markerikson]

While it's not a "lint rule" thing per se, there was a request here for some form of static analysis that would make it easier to jump from an action creator in a component file straight to the corresponding reducer:

• https://www.reddit.com/r/reactjs/comments/1ahbh7z/how_to_see_what_reducers_an_action_leads_to_more/

[EskiMojo14]

based on https://phryneas.de/redux-typescript-no-discriminating-union - a lint rule that prevents dispatches without an action creator

[Faithfinder]

"No connect in Function Components" is something I'd like now in our codebase with developers stuck in 10 year old paradigms