What's the advantage of useDispatch over store.dispatch?

[ZYinMD]

Personally, I haven't experienced any problems if I simply use store.dispatch() inside my components.

I even feel it's nicer than useDispatch in some cases, where multiple instances of the component are created, e.g. rows in a list or even table cells, because I feel the hook creates an extra "stateful thing" that each instance needs to keep track of individually.

This question has actually been asked on stackoverflow a long time ago, but didn't draw much interest.

[markerikson]

You should never import the store directly into components.

Importing the store into a component ties that component to that exact store instance. This makes your code harder to test and the component impossible to reuse correctly. Also, if you end up importing the store just to dispatch actions, but do still use useSelector to read data, now you have a mismatch in how your code is interacting with the store. (and you should definitely never try to subscribe to the store directly in a component.)

Always use the hooks to interact with the store, and wrap the app with <Provider store={store}>.

There's no "stateful thing" involved with useDispatch. As you can see here, the hook implementation is trivial - it's literally just returning store.dispatch. The important thing is that the store is being dependency-injected via context at runtime:

https://github.com/reduxjs/react-redux/blob/v7.2.4/src/hooks/useDispatch.js#L14-L17

  return function useDispatch() {
    const store = useStore()
    return store.dispatch
  }

[markerikson]

Yeah, writing a class like that is also definitely not idiomatic React or Redux usage.

In general, the React and Redux ecosystems assume plain JS data and "functional-light" programming style - no classes, no "models", no inheritance, no "public/private".

[ZYinMD]

Hi Mark, thanks very much! What's your comment on the following code that uses store.dispatch()?

// App.tsx
function App() {
  useEffect(() => {
    onAppStart();
  }, []);
  return (
    <Provider store={store}>
      <div>Hello World</div>
    </Provider>
  );
}

// onAppStart.ts
export function onAppStart() {
  // initGoogleAnalytics();
  // addAllKindsOfEventListeners();
  // applyUserSettingsFromIndexedDB();
  // await login();
  await checkPremiumMembership();
  // startPeriodicSyncing();
}

// checkPremiumMembership.ts
export async function checkPremiumMembership() {
  const status = await fetchPremiumStatus(); /* this could be "in_free_trial" |
    "trial_has_ended" | "has_paid" , etc */
  store.dispatch({ type: "fetched_user_premium_status", payload: status });
}

Would you say the store.dispatch() here is also not idiomatic? I know it can be avoided by using thunks, but that'll result in dispatching thunks inside thunks inside thunks, and writing curried functions everywhere just to get a hold of dispatch, which looks less clean, and doesn't seem to provide much benefit in return.

[markerikson]

I'm not sure how much more clearly I can state this:

Directly importing and using the store is never idiomatic use of Redux. Please don't do that.

Thunks are idiomatic usage:

https://redux.js.org/usage/writing-logic-thunks

[ZYinMD]

Yes, you have been very clear that store.dispatch() is not idiomatic. However, the original question in this thread had always been about "the disadvantage of store.dispatch()", and I still fail to see it when I have only one store, except for "not idiomatic".

On the other hand, the disadvantage of thunks are clear in some occasions: just because one tiny function needs to access dispatch, its parent functions and grandparent functions ALL need to turn into curried thunks, just for the sake of dispatching the child and child's child. Sometimes it's not a big deal, some other times it's not worth the readability. It'd be ironic if Redux solves "props drilling" but then introduces "dispatch drilling".

[markerikson]

I already gave you the answers in my first response: it makes your code harder to test and harder to reuse.