It depends on your use case, but he mentions some alternative solutions in the article.
1) React's Context API
It's straightforward to use, and it solves the issue of passing data to deeply nested components, but that's all it does.
2) GraphQL Apollo Client
I used this on a recent project for managing client-side state, and to me, it felt like I had to do a lot of work to achieve what should be basic functionality. It was my first foray with Apollo Client, so take my opinion with a grain of salt, but I found myself wishing I was using Redux instead for the duration of the project. Also, Apollo Client has some bugs related to cache invalidation (look on Github). These may be solved now, but they bit me pretty hard.
I understand how contexts can replace Redux, but can you please elaborate how they can be used instead of Apollo? Do you mean the whole of Apollo or Apollo local state?
Great article! I have only done a few simple projects with React, except for one where we used Redux. For me, Redux is too much clutter. I can recommend a look at this article: https://medium.com/@yiyisun/redux-vs-the-react-context-api-v...
I've been working on an AppRun based hobby project for a couple of months now, and I find state management there to be quite easy. No clutter!
Agreed. For large apps with even a little bit of complexity, context doesn't seem like much of a solution. You either have a million contexts for every shared state slice to optimize re-renders or you have a single context that takes a huge hit on performance. A single large context object is redux except redux knows how to intelligently update components based on what changed.
I don't get the hesitation to use redux. I've used it on every single FE app I've worked on and never regretted it. I can make redux do exactly what I want it to do and with the power we get from memoization of selectors via reselect, there really is nothing that beats it.
I'm also convinced that most people praising react-query are hugely missing out on the level of control you get with redux. Further, coupling side-effects -- e.g. fetching data from api -- with react component lifecycles is wrought with awkward edge-cases that you don't have to deal with in redux.
Every app i've worked on for the last 3 years has fit in one of two categories:
1. Minimal use of Redux
2. Started with Redux, migrating to eliminating Redux.
This has mainly been due to using other technologies for dealing with API data (i'm using Relay, but there are other options), and having relatively little need for client-side state that can't be handled at the component level. When I have needed simple shared state, I just use the context API. If I absolutely needed a lot of client-side shared state, I might still consider Redux, but would also strongly consider client-side GraphQL extensions (both Relay and Apollo support these) so that everything follows the same patterns.
Thanks for sharing. I think you touch on some of the more powerful features of Redux (middleware, selectors, pass by reference instead of value, etc.)
But IMHO a lot of that is overkill when your only goal is global state. Context solves that problem very nicely (in conjunction with state and reducer, yes, but context is the big piece there). Prop drilling was a major hurdle to global state management. But redux introduces its own overhead (Flux architecture, actions and dispatches, etc.) that are unnecessarily complicated for simple state sharing.
I feel like the article spends a lot of time differentiating the specifics of use Context vs state vs reducers, but it kinda misses the bigger point... that using those is often enough and can remove redux, leaving you with more readable and less overengineered code. Redux might be the right choice for really complex states, but it's a pain to work with day to day. Context makes it super simple by comparison.
I don't get why most projects need Redux when React has the context API already. Most people just need a place to store data shared across different components, and plain contexts do that easily.
You can effectively maintain your own component independent state via context and the context API. Where Redux shines is in predictable state management. Or more predictable depending on how you manage async requests to an external resource.
Personally, I find for mid-large apps that Redux is usually a better approach. For small-mid, you're likely better off using the new context directly. Also don't forget you can maintain in-component state.
I've been using Apollo Client and React to manage state on a medium size React app (i.e. no Redux). Interested to hear your thoughts here. Have you been using Redux + Apollo Client + React on a medium to large app?
Yeah this. We use Context to apply different themes in a multi-tenant app, and we use Redux to manage global state like the header. Both are great for their purpose.
once hooks are in, I think React Context will be a lot more usable. Right now, its composability isn't great because you have to use nested render props because it's not very HoC friendly.
React Context makes a lot of sense though, because you'll effectively be able to create your own Redux nested at any level in the DOM. This means local state will be much easier to manage and you won't have the issue of having to stuff all your disparate contextual data into one shared store.
You can use a React Context and have simple global state in your React app. If you like reducers, throw in a useReducer hook and you have a large part of what people use Redux for.
As people adopt external state containers, like Flux and Redux, it becomes increasingly impractical to bucket brigade chunks of data and callbacks to the leaves of the component tree via props. Some sort of delivery mechanism that doesn't couple in intermediate components is pretty critical to avoid having to maintain an unbounded amount of glue code. Context isn't without its kinks, but it's pretty useful in cutting boilerplate and decoupling components. The one thing I don't buy is that it's somehow worse than props from an architectural perspective (it's often compared to global variables, which makes little sense to me).
When context first came out, there was a buzz about it was going to obsolete Redux. Then it was actually "no it's not". I haven't followed it much since then. I haven't seen a code base that used a context for shared state that could be updated from descendant nodes. But I guess it pretty much has to be an improvement over redux.
Still though, the boilerplate required to do it doesn't make it seem like React is particularly good at it, even though it's technically capable.
I don't mind Redux for local state management, but it's a little overkill if you aren't using it already to handle API state.
Using Apollo on the client side makes me want to pull my hair out though.
reply