How Redux Works: A Counter-Example

I tried to call this out in the article to make sure people are aware that improving simple Counter examples is not what Redux is really meant for.

I'm considering putting together a larger course/book that does just what you say - build up a React app using plain state until it becomes painful, and then refactor it to add Redux. My question right now is, how far should I go? Do I walk through building the entire app with state (and push through the complexity), or do I give up at the first indication that Redux would make things easier?

I'm hesitant to see new programmers avoiding a "learn the hard way" project. Without it, there's so much they might never grok.

Beautifully said. The same goes for schema-less data models. The full appreciation of foreign keys, data type validation, and check constraints doesn't kick in until you try incrementally changing a NoSQL spaghetti app.

Redux, on the other hand, expects you to dive into the deep end head first the first time you use it. I teach javascript development, and I'm noticing there's a pretty big gap where you're feeling the pain of React, but Redux is still too large a complexity tax (To be fair, even to an experienced programmer it often is - for every complex state change that warrants Redux there's 50 straightforward "change this field" or "toggle this boolean" actions.)

Maybe this isn't the responsibility of Redux, and something should be built on top of it, but there needs to be some amount of consensus on what the best solution is.

Which it is, actually!

Think about how MVC works in iOS, or ASP.NET MVC or JSP Model 2, etc. In the case of the latter two, your state is stored in the session as simple, regular objects. Have you felt the need for actions and reducers and immutability etc. when using session state? I have not.

When programming JavaScript SPA, you can program in the style of MVC also. There is no need for actions, reducers and so on, unless your app is for example a word processor and you need undo/redo (as mentioned by another comment on this thread.) Most of the time you are getting data from the backend, temporarily storing stuff in memory, modifying it and sending it back to the backend. There is no need for actions/reducers and such other nonsense for that.

When I mention this someone always points me to the "you may not need redux" article by the creator of redux, in an attempt to legitimize some use cases of redux. There may indeed be some legitimate uses cases for redux. But it has become the de facto standard way of building React applications, and that's totally unjustified.

What this will let you do is basically extend your server-side GraphQL API with a set of local resolvers for queries and mutations, and let you query and mutate both your server-side and client-side state using a single consistent API (GraphQL, with client-side fields decorated with a @client directive), backed by a (mostly) automatically normalized local state cache (by default apollo-cache-inmemory, but customizable, so you can even implement a Redux based cache if you'd like more control).

A lot of the complexity in Redux today stems from the need to reconcile client-side state with server-side state, usually fetched through some kind of async actions paradigm like Thunks+Promises, Saga, Observables, etc, to be then manually merged into the local state after being transformed into a normalized form.

I personally think one of the biggest problems with the design of Redux is that the architecture derives most of its benefits from having a normalized state tree, but it also makes it all too easy for developers to store non-normalized data in the state tree. Although admittedly an architecture that does enforce a normalized state tree would be an order of magnitude more difficult to learn and work with in the wild-west of RESTful APIs that used to be the de-facto norm back in the days when it was designed (and it still is, though that may be slowly changing with the rapid adoption of GraphQL), where most server-side data you receive isn't easily normalizable to begin with.

A good GraphQL client like Apollo can already abstract away much of the complexity involved with async server requests through its Higher-Order Component-based API, which simply provides data to the wrapped component as props, so it doesn't need to know how to fetch that data. More importantly though, Apollo also ensures that all the server-side state it maintains in its cache is stored in a normalized manner, and GraphQL makes this fairly easy.

Apollo-link-state goes a step further and allows you to use the same abstractions for managing client-only state, and store it in a normalized form alongside your server-side state, to allow for a much more consistent and comprehensive state management API.

With all that said, apollo-link-state is still really young and I've only played around with it briefly in toy projects, so there's no guarantee it could scale as well to large teams as Redux has. I do still personally find it to be one of the most promising alternatives out there though.

Lastly, Relay Modern also supposedly has something called Client Schema Extensions, which I assume is similar to apollo-link-state, but wasn't able to find any documentation on it outside of a brief mention in its release notes: https://facebook.github.io/relay/docs/new-in-relay-modern.ht...

> Dan Abramov, just now : "if you want to teach someone why to use an abstraction, you should first make them feel the pain of not having it"

But yes, it's tough to try to show the value of Redux while at the same time keeping the example simple enough to illustrate the basic mechanics.

You're not wrong, but practically 99% of people pair it with react.

In any case, it's led to a ton of confusion in the community, especially for newcomers.

Second - it's interesting you found the reverse approach to be confusing. I've heard from multiple people that loved it and said it made more sense to them that way. Different strokes and all that!

How experienced were you as a dev before you read the Redux docs + Dan's tutorials? I ask because I learned with those too, and they made sense to me (Dan's egghead videos were eye-opening), and I've been doing software for > 10 years professionally... but my suspicion is most beginners don't do as well with the top-down approach.

I've seen feedback that Dan's teaching style is the greatest thing ever, and feedback that it requires a giant leap of faith that "we write thing A, and thing B, and thing C, and magically they all work together at the end". Clearly, different people have different learning styles. Dan and Andrew _did_ try to write the docs in a way that would be accessible for people with varying backgrounds, but it's tough to write docs in a way that works for everyone.

If you or anyone else has suggestions for improving the docs, please let me know! I'm always open to ideas for improvements. Please ping me on Twitter at @acemarke, or file an issue / PR in the repo.

[0] https://redux.js.org/docs/advanced/Middleware.html

[1] https://github.com/reactjs/redux/pull/140#issuecomment-11371...

[2] https://twitter.com/dan_abramov/status/622568094939090944