Redux vs. The React Context API
daveceddia.com
daveceddia.com
"Context is what powers React Redux under the hood. The new context API isn’t to “replace Redux”, it just fixes a broken feature that needs to be provided by React. Whether you use it directly or through another API like RR is up to you" [0]
At the end of the linked article the author states "Today, when Redux is more than you need, you can reach for Context." I'd actually argue the opposite. Redux, specifically React-Redux, is an abstraction. An abstraction that simplifies using the Context API. All I need to think about when using Redux is Flux architecture. There is excellent documentation around Redux, context api not as much.
If you don't feel confident about Redux, or would like to get a better understanding of it, check out these three things (in order):
1. Understand Flux Architecture: https://facebook.github.io/flux/docs/in-depth-overview.html#...
2. Understand Redux: https://egghead.io/courses/getting-started-with-redux
3. Implement Redux: Read the documentation at https://redux.js.org/. At this point you should have a good grasp on the concepts so pay attention to implementation details here like designing the state.
[0]:https://twitter.com/dan_abramov/status/964946781493780480?la...
This article is looking at the new Context API, which uses React.createContext() to create a Provider/Consumer pair of plain components. This has a number of differences in behavior, most critically around blocking updates incorrectly.
We are looking to switch to the newer API in 6.0. We have two in-progress PRs for this:
To me, this is yet another perk of using RR on top of the actual api. As someone who works on a smaller team, updating our projects to use the new context api would be a significant undertaking. By using RR, the implementation details are left better equipped engineers, our team can focus on meeting business requirements.
Context is the mechanism by which state is passed through to components. Redux solves management and lifecycle of that state as well.
I made my own state management framework with context, but it’s basically a less polished version of unstated if you want to check that out. Much saner. Much less cruft.
That pretty much sums up why I wrote this article :) After the new Context API came out, a lot of people started saying that it would replace Redux, and like you said, they only really overlap in that they can help avoid prop drilling. Redux is more powerful, out of the box anyway.
[0]: https://github.com/mathieudutour/redux-throttle
[1]: https://github.com/mattkrick/redux-optimistic-ui
[2]: https://github.com/rt2zz/redux-persist
(to be pedantic, some of these are not solely middleware)
I used to think props were good for dynamic components, but with portals available, I rarelyconsider them a good pattern for anything but components shared between applications.
I use context to pass down actions. IMHO, mapping those into state should be deprecated.
It means that components are more coupled to the state, but way way less coupled between them. Which I find to be easier to work with!
The last codebase I saw that was written with an HOCs-first perspective was rendering every HOC on every prop trigger. It still gives me the twitches :)
Not exactly sure what you mean by that? Selectors are a redux thing for me, I don't understand what you mean by not using redux but subscribing to selectors
> The last codebase I saw that was written with an HOCs-first perspective was rendering every HOC on every prop trigger. It still gives me the twitches :)
I don't see how that's a problem. Just because you render a bunch of wrapper components (one for each HOC)? React is extremely efficient at rendering this kind of components having only one child
https://github.com/reduxjs/reselect
> Just because you render a bunch of wrapper components (one for each HOC)?
Efficient rendering would involve >not< re-rendering the child on every prop render, but only when the relevant props have changed. Connect does a shallow comparison, so all the props need to be immutable for it to work.
You can use immutablejs to make your object props immutable, but this gets messy fast. I have found it easier to use selectors, and have changes land when an actual change happens, rather than checking for them or organizing your data to facilitate change detection (rather than organizing your data to make it easier to think about).
I try and limit context to the things that are used across the app, but are not coupled to a given component. For example the user’s session, environment specific behaviour, or theme information.
Most of the time I feel that global-ish data like that shouldn't be passed/exist in the first place. Context is a doubly dangerous place for it, since it can go stale.
I take that back. I'm am accessing this kind of data - via the actions I'm passing down. They are `getStore`ing anything they need.
Anything else that needs to have the data >should< access via props, or the redux store is no longer the single point of truth.
Footguns, footguns, everywhere.
And us, with four left feet.Redux was a “wtf” as it grew in our app and was a real struggle to back out of.
My current personal project is a video game drum controller trainer that I am writing in Bacon.js streams instead of redux. So far it's been a mindbending experience - I'll have to master it before I know if it's any good :)
Someone commented that the power of redux should not be underestimated and that is absolutely true. It is also true that the complexity of redux should not be underestimated. My code bases have been greatly simplified.
In my limited experience the Context API covers 80% of the use cases that required redux, with 80% less complexity. I am sure I will use redux in the future, and I am a better coder for having learned it, but my experience with Context has been very positive.
* Context is a dependency injection utility. * Redux is a state-management library.
Redux doesn't know anything about React. In order to use it with React you need to use ReactRedux, which actually uses Context to do it's thing.
The comparison being drawn with the article is still the old:
> React Redux vs React State.
The difference now is that React has a new (and substantially better) Context API.
FYI, I'm a Redux maintainer. We are currently working on an internal refactoring of React-Redux's `connect` so that it will use the new `React.createContext` API instead of legacy context. We've got two open PRs with "competing" reimplementations, and I will actually be spending the rest of today hacking on those.
The immediate goal is to make React-Redux at least compatible with React's upcoming "async rendering" capabilities. However, we do have some difficult problems to solve in order for Redux to take full advantage of the "Suspense" feature. We've got a decent idea what the problem space is, but we need some more examples and guidance from the React team so we can try to work on a solution.
Side note: we're also hoping to completely rework the React-Redux docs (since they're mostly just a jargonistic API reference in a Markdown file in the repo), and we're also considering a restructuring / reworking of the core Redux docs as well. Would love to have some suggestions or even additional volunteers to help us!
Issues/links for reference:
- Roadmap: https://github.com/reduxjs/react-redux/issues/950
- v6 WIP PRs: https://github.com/reduxjs/react-redux/pull/995 , https://github.com/reduxjs/react-redux/pull/1000
- React-Redux docs: https://github.com/reduxjs/react-redux/issues/1001
- Redux core docs: https://github.com/reduxjs/redux/issues/2590
Leave a comment in issue 2590, or DM me on Twitter or something - happy for any assistance you can offer!
How much conversation is there with the ngrx (AngularRedux implementation with Redux as a leaf-able RxJS stream) folks? This is essentially an async integration, wondering if there is some good additional idea exchange to be had there.
Honestly, the NgRX team is completely separate and we don't talk. I proposed a get-together back in March when I was out in SF for a few days, but it didn't pan out (see the thread before and after this tweet: https://twitter.com/acemarke/status/969035239392776193 ). I'd love to have some discussions to see where we can maybe share some ideas, see where the ecosystems actually overlap, etc.
The new context API (`React.createContext`) is intended to be stable going forward. As far as I know, the only potential "unstable" aspect remaining is the `changedBits` prop for potentially optimizing which consumers actually update on a given context value change. So no, I don't have any particular reservations at the moment. Legacy context still works but is very deprecated, and new context allows us to refactor the internals in a way that's ultimately simpler and hopefully more compatible with where React is going.
Can you point me to some of these ReactReason discussions?
It's one of the big reasons our company isn't even considering ReactReason at present. Lack of support for version 16 APIs is killer when you already have stuff depending on them.
Gotta love the contextual marketing in a still-useful article. This made me realize content marketing combined with educational tools in an underrated small business idea, which I'm sure could apply to a hundred small niches when done right by legitimate domain experts.
I bought Dave's book a couple of months ago. It's overpriced in my mind (it's more like half a book and stops short of delivering what I think most people would expect or want, i feel) but he is a good writer and what is in the book is pretty informative and solidly instructional.
While I intentionally kept it focused on "pure React" because I felt that a big part of the "React is hard" sentiment seems to come from how much other stuff gets lumped in with it (and then people feel compelled to learn it all at once), I've been considering expanding it to include some other tangential stuff e.g. API calls, basics of testing... any other ideas would be great to hear!
I'm a mostly backend programmer and i remember when i was done with the book thinking "ok i can shoe horn my ajax calls into this but I don't feel confident this is how I'm supposed to." ultimately I got set straight on IRC and discord.
I do enjoy your writing style and your blog posts though, and honestly did find your book helpful.
Pricing is hard :/ Price too low, and people don't take it seriously. (e.g. $9 for 35 hours of video). Price too high and people run away. It was my first product, too. I looked at it as, "how many hours would this save someone?" Filtering through bad tutorials, just-in-time googling, all that stuff. Of course with front end there are a billion other learning resources out there, lots free, lots cheap. Hopefully the book is a more direct path than some of those others. Always room for improvement and experimentation of course :)
I've used flux, redux, mobx, context, combinations of those, and I think I finally found something that will stay.
If you haven't tried it, I highly recommend it!
Redux is nice if you need more predictable interactions, for example when you need undo.
With Redux and Context, you might have test setup code always populate the store with reasonable defaults for the 20 different data dependencies. Then, a typical test might update a few things in the store with test-specific values, render <Nav /> without the need to specify any props, and then perform interactions, inspect the results, etc. There's more going on behind the scenes, but it's also easier to get started because you don't need to figure out 20 props.
(There are many, many ways to think about testing here, though, and this is just one approach.)
If you want to test the connected component, it's still good to separate them as you won't test the same things (correct props are passed down, rather than UI renders)
As one (admittedly extreme) example, a while back I hit an issue where a refactor caused a very simple crash: just load the app, click a particular button, and it immediately crashes. All relevant components, actions, stores etc had extensive unit tests, but there was no test to make sure that the component dispatched an action that was compatible with what the store wants. I wrote an integration test for it, "load the app and click this button, and assert the intended effect", and it ended up being about 5 lines. It exercised the same code paths as the hundreds of lines of unit tests, and gives me much more confidence in the overall correctness of the system.
I'd like to move to a page-based testing, where I mount the entire page and interact with it, asserting what's going on visually and in the store
The costs of deep prop trees 1) kills many performance benefits offered by a good react/redux setup 2) makes it hard to build off of the state (much like a monolithic codebase) because it can be harder to find if something is already there or not.
1. unit testing on the smallest bits (Redux actions/reducers make unit testing them SUPER easy)
2. do e2e with something like Cypress.
Anything in between can be helpful but I found it can be too tedious, or difficult to do and ultimately, unit/e2e catches most things
Off to refactor...
Anyway, as soon as I realised that the two are complimentary, I was always kind of upset at articles like this that misled me for so long.
FWIW, it's not "just" about new context - there's a lot of other aspects we have to take into account, including trying to figure out how to best make React-Redux work with the upcoming "async rendering" capabilities of React, as well as the multitude of ways the community is using React-Redux beyond just the standard patterns.
It's good to know that everyone is together with bringing on async rendering. Thanks for your efforts!
Context solves the problem of passing props to nested components.
Context doesn’t replace Redux because they solve different problems. This is also evident in the fact that Redux internally uses Context to pass props.
Also, as a side note: we're open to adding a render props-based API at some point in the near future, since there's a number of people who have expressed interest in that.
// with connect
import { connect } from 'react-redux'
import { defaultSomething } from 'src/store/ducks/something'
const Whatever = ({ something }) => <div>{something}</div>;
export default connect(state => ({
something: state.something || defaultSomething
}))(Whatever);
// with consumer
import { identity } from 'ramda';
import { SomethingConsumer } from 'src/store/consumers'
const Whatever = () => <div><SomethingConsumer>{identity}</SomethingConsumer></div>;
export default Whatever;
// with consumer
import { SomethingConsumer } from 'src/store/consumers'
const Whatever = () => <div><SomethingConsumer /></div>;
export default Whatever;
Perhaps it's just that I'm very used to `connect` as the "standard" way of doing things, or that I don't use TS myself, but I'm really not seeing that much of a change in those examples (especially if you're importing pieces from other files that already abstract some aspect of the process).
After we get done with version 6 (update to use new context), we are open to ideas for new API approaches for a v7. If you've got specific suggestions, please either file an issue, or wait for us to open up some discussions and give us your thoughts then.
Don't think so, but I still feel like Vuex is better than Redux and Context API.
// Note that it's named with UpperCase, not camelCase