react-community-tools-practices-cheatsheet VS reselect

Eh, there was entirely valid reasons for the backlash :)

Redux _was_ overused in the first couple years. The original patterns _were_ very boilerplate-y. There _are_ a lot of other good tools for varying use cases that overlap with things that people have used Redux for: Context for prop drilling, React Query / Apollo for data fetching, Zustand/Jotai/Mobx/five-million-other-libs for state management.

Redux will never be the "must use this" lib again the way it was there for a couple years.

And that's a _good_ thing, because folks should take time to think about what problems they actually need to solve in their apps and pick the tools that work best for those problems.

But it's also true that Redux _is_ still a useful tool, and that RTK has addressed the pain points in using Redux. So, still very much a viable choice today, and the positive feedback we get on RTK daily shows that.

Really, the bigger issue today is that a lot of folks don't seem to understand the technical differences, tradeoffs, and intended use cases between a lot of these tools.

I wrote an extensive post describing the differences between Context and Redux to try to help with that:

- https://blog.isquaredsoftware.com/2021/01/context-redux-diff...

I've also been trying to start up a community-driven site to list common tools for various use cases (state management, styling, build tools, data fetching, etc), to act as a resource to help clarify this sort of confusion:

- https://github.com/markerikson/react-community-tools-practic...

Sadly I haven't had time to push it forward myself due to all the other responsibilities and tasks on my todo list, but hopefully at some point we can get enough info filled in for it to be a real resources that we can point people to.

In fact, I am literally trying to put together a community-driven site that would list commonly used tools for use cases like state management and styling, and describe their tradeoffs, specifically because I want people to make informed decisions.

Good question!

The really short answer is: mostly looking at NPM download stats, Github "depended by" numbers, and random polls on Twitter.

Which are all _horribly_ flawed metrics, but they're also all we have to go by.

I wrote a couple longer comments on Reddit a while back that went into more details on some of the numbers and the potential flaws in using them:

- https://www.reddit.com/r/reactjs/comments/lcgqnd/state_manag...

- https://www.reddit.com/r/reactjs/comments/skbyb1/the_most_po...

and unfortunately you asking me about this is tempting me to turn those comments into a blog post with some additional thoughts :)

I'll definitely agree that Redux usage has peaked in _relative_ terms, although as you can see from the download numbers it seems to still be growing in _absolute_ terms. Also it's entirely possible that fewer new projects are choosing Redux.

Then again, how do we even count "usage" in the first place? I've seen Web3 app boilerplate repos that include Redux Toolkit. If 1000 people clone that repo and play with it, how do we compare that usage conceptually vs one app using Mobx that's been around for years and has a bunch of developers working on it daily?

As I've pointed out in a number of podcasts and articles: I'm not trying to convince people they _must_ use Redux, or even that they _should_ use Redux. I just want people to be aware that modern Redux is way easier than legacy Redux, that Redux _is_ still widely used and is a viable choice, and what some of the tradeoffs are when using Redux or any other state management library.

I've actually been trying to get the community to come together and work on a centralized site that would list tools in different use cases and categories such as state management, styling, data fetching, and build tooling, describe purpose / use cases / tradeoffs for each tool, and have that as a recognized resource for people to use when researching what to use for a project. You can see the original RFC discussion and prototype site here:

- https://github.com/markerikson/react-community-tools-practic...

- https://react-community-tools-practices-cheatsheet.netlify.a...

Sadly I haven't had time to push this forward, and it needs to have more people involved and helping fill out content on the various topics (not just me).

Fortunately, we're starting to make some headway on https://github.com/markerikson/react-community-tools-practices-cheatsheet/discussions/1 ! We recently got a PR adding a page covering the three Poimandres libs (Zustand/Jotai/Valtio), someone's filling out pages on styling approaches, etc.

(I will say this is the exact kind of guidance I'd like to have in the "React Community Tools" site I still want to build out as a resource, and I'm hopeful that we can get some content filled out and momentum behind that site later this year.)

Early last year, I proposed creating a "React Community Tools and Practices" resource site. The idea was to provide curated written guidance on the different tools and techniques that React devs commonly use to solve various problems, describe the purpose and tradeoffs of each tool, and give some general guidance on how to decide on what tool best solves your use case.

Background: https://github.com/markerikson/react-community-tools-practices-cheatsheet/discussions/1

- Throws better errors in an RSC environment

- https://github.com/reduxjs/react-redux/releases/tag/v9.0.0

## Reselect 5.0:

- Switches to a new `weakMapMemoize` memoizer as default

- Renames `defaultMemoize` to `lruMemoize`

- Allows passing memoizer options direct to `createSelector`

- Many TS improvements

- https://github.com/reduxjs/reselect/releases/tag/v5.0.1

## Redux Thunk 3.0:

- Drops the default export and switches to named exports ( `{thunk, withExtraArgument}` )

- https://github.com/reduxjs/redux-thunk/releases/tag/v3.1.0

This has been a _huge_ year-long development effort!

We're thrilled to get these improvements out. The tooling and bundle improvements will help all users, and we think the features and TS changes will improve the Redux dev experience significantly.

Thank you SO MUCH to everyone who has contributed or helped test out the work!

Please file bug reports for the inevitable issues that pop up post-release!

but now I'm going off on a conf trip and going to take a very well-earned break from Redux work for December :)

reselect -> For making faster queries to store.

Reselect solves this problem by memorizing the values and only passing what’s necessary.

In addition, diagnosing bugs in how data flowed through the application (where data originated from, how it was changed, etc.) was always super painful because I had to backtrack through selectors referencing selectors referencing selectors. And updating high-level selectors risked breaking something else down the line (even with 100% business logic coverage this was a problem). (This may be chalked up to improper usage of reselect, but I'm curious to hear your thoughts. Is this a common problem?)

reselect : Selector library to optimize your store access

Reselect documentation:

Applying memoization to TypeScript and ReactJS is relatively straightforward. There are several libraries available that provide memoization functionality, such as memoize function from Lodash, reselect or hooks from ReactJS. These libraries can be installed using NPM or Yarn and used in your TypeScript and ReactJS projects.

Generally, all you would need is to have your redux store provider at the very top level of your application (You could also only wrap the components that you want to have this data available to). Then, any component rendered inside that provider can get access to the redux store. The suggested approach ever since hooks were released is to use `useSelector` and `useDispatch` within your component to get the state data that you need. Using a selector library like Reselect is prevalent and keeps your data selection tidy & handles memoization for you.

Reselect is a library for creating memoized “selector” functions. Commonly used with Redux, to slice state and provide just the necessary subtree to a React component.