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

[binarykitchen]

Hello state management folks 👋

(Perhaps this is not just about state but also about emotion, or are both the same? lol)

In short: I support the idea, redux-toolkit truly needs a ESLint plugin to maintain popularity.

It's actually funny. About 8 years ago, I loved RTK/Redux, its concept of an immutable single source of truth. Then, due to company changes, checked out other frameworks like re-frame (Clojure), or mobX, indulged the React Context API with a hiccup, loathed Recoil etc. .... and now I am coming back to here. Why? Because I still dig what @markerikson has set up.

The longer version:

• I ran a search on npm + GitHub for code related to redux-toolkit. Most of the results are ancient, unmaintained. Why ancient? In software development, no updates past 18 months equals to a half-life of 50%
• This makes newbies and also AI agents back off, not checking out anything related to redux-toolkit.
• Most of those who starred redux-toolkit are more senior, elder software engineers.
• Numerous comparisons between JS-based state management libraries are outdated. Most of them say, redux-toolkit has too much boilerplate, which is not true. For example, the configureStore() fn reduced lots of boilerplate, which is great but hasn't been honoured in those comparisons.

Anyway, back to topic:

• To pump up redux-toolkit, we need fresh stuff
• Revive the community
• Build an ESLint plugin together
• Find sponsors, receive donations
• Do marketing, make some noise, etc.

Happy to brainstorm further.

Good night from New Zealand 👋

[markerikson]

@binarykitchen heh, appreciate the enthusiasm :) fwiw I don't think that adding official lint rules is going to change anyone's opinions of RTK.

The "boilerplate" meme is, sadly, embedded at this point. I do see a lot of folks say that RTK itself is still too much boilerplate compared to libs like Zustand or Jotai. That's a valid opinion to have, and nothing we can do would make people suddenly change those opinions.

As for NPM package activity... yeah, probably the case that there's not a lot of new packages related to Redux over time. Like any other community, once the early pieces get filled in, activity will slow down. See things like Wikipedia or Stack Overflow as examples. Plus, RTK was intended to replace a lot of the community-written packages with official implementations.

Plus, all tools have a lifecycle anyway. They get popular, people realize the pain points after using them for a while, something else comes out that's new and shiny.

Don't get me wrong, I want people to use Redux :) But our stance has always been "we're not trying to push this, there's plenty of good options, we're just building a good toolset that works well if you choose to use it".

[binarykitchen]

Thanks, mate

The "boilerplate" meme is, sadly, embedded at this point. I do see a lot of folks say that RTK itself is still too much boilerplate compared to libs like Zustand or Jotai. That's a valid opinion to have, and nothing we can do would make people suddenly change those opinions.

Hm. I do witness myself that RTK has actually reduced the boilerplate. If people still believe the opposite, isn't that actually a wrong opinion instead of a valid one?

Of course, in politics, everyone is allowed to have their own opinion, but this is about computer science, isn't it?

Plus, RTK was intended to replace a lot of the community-written packages with official implementations.

Yup, awesome job, thank you.

Plus, all tools have a lifecycle anyway. They get popular, people realize the pain points after using them for a while, something else comes out that's new and shiny.

RTK is still shiny. The fact alone that I still come back to it after many years says much. And your documentation is remarkable. Much Respekt.

Don't get me wrong, I want people to use Redux :)

Me too :)
I'm getting sick of poor state management. Especially when you have projects with > 200 React hooks 😅

But our stance has always been "we're not trying to push this, there's plenty of good options, we're just building a good toolset that works well if you choose to use it".

Ah.

• (a) Letting users choose it the passive way, or
• (b) make some noise, marketing and debate about invalid opinions?

Those are two different stances. I totally understand. For a long time, I ran my hobby project https://www.videomail.io the (a) way, but later realised, with (b) you'll get more attention and success.

[markerikson]

Oh I completely agree it's a "wrong" opinion :) If you look at a Zustand store and an RTK slice side-by-side, there's very little extra / boilerplate-y code in RTK usage. But that's kinda my point - can't bash people over the head and try to change their minds, and a lot of those opinions are embedded in both the general JS ecosystem and in people's minds. Folks are allowed to have their preferences on tools, and "I like Python/TS/Go", "Express/Hono/Elysia", "Redux/Zustand/Jotai", are all valid opinion preferences to have.

And, tbh: I've spent ridiculous amounts of hours debating people about their Redux misconceptions over the years. Most of that pushing back on the "boilerplate" meme, and saying "you ought to be using RTK, it addresses those issues". I still do it (and even have done a "Why Use Redux Today?" talk at a couple confs in the last couple years), but at this point I'd rather spend more of my time trying to work on the lib than having yet another debate. I definitely push back on real misunderstandings, but XCKD's "someone is wrong on the internet" is a warning, not a recommended way of life :)

[binarykitchen]

Aye, me too, I agree with that. Sometimes it's not worth the debate, but wiser just to continue improving the library.

Thanks for the exchange 🙇