useStore is way more valuable than the docs suggest

[dwilt]

The useStore docs say:

This hook should probably not be used frequently. Prefer useSelector() as your primary choice. However, this may be useful for less common scenarios that do require access to the store, such as replacing reducers.

I wanted to address why I think this should be re-worded and discuss something I don't hear/see much talked about in the Redux community of why useStore is so valuable.

We have a pretty complicated (feature and performance-wise) application with thousands of components on a page, heavy virtualization, with drag and drop. We have had to do extensive work on ensuring we don't have extra re-renders in our components (and thus, especially in our shared hooks) because the effects could be very large.

One of our key techniques to preventing unnecessary re-renders with regards to data from our Redux store has been accessing the Redux state on the fly when we don't need that data bound to the ui. In smaller scale apps, binding the data to the ui (aka useSelector) works just fine. But as the app grows, this can grow into a real re-render issue. Let me show a basic example.

Bad for performance

export const MyComponent = () => {
  const val = useSelector(someNeatSelector);
  
  const onClick = useCallback(() => {
    callSomeEndpoint(val);
  }, [val]);
  
  return <Button onClick={onClick}>Click me</Button>
}

The problem here is that if val changes in Redux, this component will re-render. Now, it's just a button that will be re-rendered, so it's not a big deal. But if this selector was being used in a shared hook (and who's not writing reusable hooks with lots of shared logic these days?) this has the potential to cause lots of unnecessary re-renders.

We asks ourselves this: if the UI isn't visually changing, we probably don't need to cause a re-render. React is, at its core, a view library.

In the above example, val isn't used in the UI - just in the callback. Updating the callback just because val updated isn't necessary. Instead we can go get the value of val on the fly when the user clicks. Like so:

Better for performance

export const MyComponent = () => {
  const store = useStore();
  
  const onClick = useCallback(() => {
    const val = someNeatSelector(store.getState());
  
    callSomeEndpoint(val);
  }, [store]);
  
  return <Button onClick={onClick}>Click me</Button>
}

I'm calling this out because although useSelector is the obvious choice when you want to bind your data to the view, I'd argue useStore is the one you'd want to use when you don't. And I think there are a lot of use cases in a traditional app and something most developers should be aware of.

[markerikson]

Hmm. So I definitely understand the "don't want to unnecessarily select data and cause re-renders" problem you're describing. However, there's two other options here that also work around the issue of needing access to the state at the time of a click without re-rendering, and neither of them requires the actual store instance.

The first is to move this logic out into a thunk:

const someThunk = (argFromComponent) => {
  return (dispatch, getState) => {
    // do whatever logic is necessary here 
  }
}

// then, in a component
const handleClick = () => {
  dispatch(someThunk(someComponentStateValue))
}

That way the logic that actually relies on the Redux state can access getState as needed, and the component doesn't have to care about it.

The other option is an amusing but technically valid abuse of thunks:

const selectSomeStateThunk = (anySelectorFunctionHere) => {
  return (dispatch, getState) => anySelectorFunctionHere(getState())
}

// then, in a component
const handleClick = () => {
  const theSelectedState = dispatch(selectSomeStateThunk(selectSomeData))
  // do more logic with the selected value
}

This works because the thunk middleware causes dispatch to return whatever your thunk function returned. That pattern is typically used for returning a Promise and letting the component wait for async logic to complete:

• https://redux.js.org/tutorials/fundamentals/part-7-standard-patterns#thunks-and-promises
• https://redux.js.org/tutorials/essentials/part-5-async-logic#checking-thunk-results-in-components

Now, I'll agree that useStore is a legal thing to call, and perhaps slightly more valid to call than the docs suggest here. Part of that is the historical emphasis on not letting components actually know anything about a "store" or "dispatching" - the whole "container component" paradigm emphasized components just calling props.doSomething() and not caring if it was a bound Redux action creator, a thunk, a prop from the parent, or a mock function in a test. Clearly that has changed.

But, I would still recommend trying to avoid directly referencing the store in a component if needed, and in this case I'd prefer one of the thunk-based options instead of useStore.

[dwilt]

I come from a thunks and sagas background so I appreciate the thunk approach but we've actually been moving away from them in our codebase and instead storing their logic in hooks for a few reasons:

1. Thunks and TypeScript are much less ideal than hooks and TypeScript
2. Currying isn't a pattern devs see too often anymore in the React ecosystem and keeping things familiar and consistent is good for large codebases with different skill levels of members on the team

[markerikson]

Hmm. I'm afraid I'd have to disagree with both of those statements.

Thunks work just fine with TS, and we specifically document patterns for typing thunks correctly:

• https://redux.js.org/usage/usage-with-typescript#type-checking-redux-thunks

Also, thunks have been a standard part of Redux logic since the very beginning, and we have recommended their use for years:

• https://redux.js.org/style-guide/style-guide#use-thunks-for-async-logic
• https://redux.js.org/style-guide/style-guide#move-complex-logic-outside-components
• https://redux.js.org/usage/writing-logic-thunks

So this is a "familiar and consistent pattern" for Redux.

For the record a thunk isn't actually "currying" per se. It's just one function (a "thunk action creator") returning another function (the actual "thunk function").

If you really want to put that logic in hooks, you're entirely welcome to do so in your own codebase, and it'll work fine. But thunks would still be our recommendation here.

[dwilt]

1. I'm not saying thunks don't work with TypeScript but is less than ideal compared to hooks. There is definitely a lot more you have to type to get it working correctly out of the box (as noted by the caution callout on that page you linked me to about useDispatch not being inherently typed).
2. Yes, in the world of Redux, thunks have been here from the beginning. But you don't see this pattern much outside of Redux

[phryneas]

I'm late for the party!

As for 1.: useStore is also not inherently typed to give you your store instance with a correct state type - I would argue that here you have to take the exact same step.

(Tbh., I never use a AppThunk type, I just write thunks like (dispatch: AppDispatch) => { ... } or write them inline in a correctly-typed Dispatch call, where no types are needed at all.)

I would suggest a helper function like

function dispatchableSelector<T>(selector: (state: State) => T) { return (_: unknown, getState: () => State) =>  selector(getState()) }

you can use that everywhere in your application like

const value = dispatch(dispatchableSelector(state => state.foo.bar))

[mechaniccoder]

I think side effects can be restricted by abstracting logic using hook

const { get: getBar } = useStoreSelector(state => state.foo.bar)

const handleClick = useCallback(() => {
  const bar = getBar()
}, [get])

[codegeordie]

But, I would still recommend trying to avoid directly referencing the store in a component if needed, and in this case I'd prefer one of the thunk-based options instead of useStore.

Is there a technical reason why this should be avoided?

[phryneas]

No, a "code sanity" and "teaching" one.

People will after a while of copy-pasting start accidentally using store.getState() instead of useSelector during render and after that point you will see weird behaviour like components not rerendering when they should etc.