| MobX | Redux | Context + Hooks | Easy Peasy | Recoil | |
|---|---|---|---|---|---|
| Status | stable, being used in Production at large companies | battle tested in large scale production apps | experimental | ||
| multiple stores | multiple reducers | multiple contexts | |||
| Tooling | Redux DevTools | ||||
| Verbosity | verbose, but Redux Toolkit to the rescue | verbose, but useContext is cool |
Observable pattern. In MobX you can directly edit the state tree, unlike Redux where you must dispatch actions in order to update state.
data fetching and side effects included
There isn’t much difference in complexity or verbosity. You still gotta wrap stuff around and write all the reducers and disptach all the actions. The functionality is pretty much the same. The code is also fairly similiar (specially the reducers and dispatch)
By the looks of it, Context isn’t providing anything new or solving an issue better. It’s just replicating what Redux already does, minus the DevTools.
Redux vs React Context hence is not even a competition.
Context is a way to share state between unrelated or distant components. All you have to do is wrap your components in a
Context.Providerand then calluseContext(Context)inside that component to access your state and helper functions.
You have to use useContext() with useReducer(). useReducer() provideds the logic for updating your state, give shape to the data in your state..
In your folder structure, you’ll have a contexts instead of store folder
1import React, { useContext } from 'react'
2const { loading, data, more } = useContext(MyContext)
With React Context, the meat of the code is in the Provider. That’s where you write your reducers. Creating the context is just creating a constant, and using the context is also just creating a constant with useContext(). Unlike Redux, there are no action creators.