Why we decided against GraphQL for local state management

I largely came to the same conclusion, including going back to Redux. I have found using Apollo for client side state very cumbersome and even difficult. You really do need to understand their cache well, and I also dislike having to deal with things like __typename, which I feel is an implementation detail that unfortunately gets foisted onto the end developer. Sometimes __typename is a royal pain in the butt.

The article touches upon current Redux as well, such as when it says "If done right, it can definitely be a breeze to work with", which I agree with. And the "if done right" part has gotten a lot easier, as Redux has finally decided it's ok to provide opinionated approaches that guide you towards that happy path. I really do think if Redux hadn't been so concerned about being opinionated way back when, it'd be far better received today. But better late than never.

I would definitely encourage all of my competitors to use GraphQL. Nothing like getting a free six-month lead.

That's two months they spend learning GraphQL, two months introducing a mystery-meat binding layer and learning that, and two months debugging it all and pulling their hair out.

And no, using a giant third-party lock-in toolkit like Hasura or Apollo is not a response.

> I really do think if Redux hadn't been so concerned about being opinionated way back when, it'd be far better received today

Can you clarify what you mean here?

From my perspective as a Redux maintainer, most of the concerns I've seen expressed about Redux over the last few years really didn't focus on whether it was "opinionated" or not. It's been a combination of:

- Not understanding the original intent behind Redux's design and the historical context that led to it being designed that way [0]

- People being told they _had_ to use Redux with React, even when it really wasn't a good fit for their use case

- The "incidental complexity" of common Redux usage patterns [1], most of which were due to the way the docs and tutorials showed things (writing `const ADD_TODO = "ADD_TODO"`, separate files for actions/constants/reducers, etc).

- Changes in the ecosystem leading to other tools whose use cases overlapped with why you might have chosen to use Redux previously

All that said, yeah, we've made a concerted effort in the last year or so to be much more opinionated about how you _ought_ to use Redux, based on how we've seen people use it. Those opinions are built into our new official Redux Toolkit package [0], which is now our recommended approach for writing Redux logic, and the Redux Style Guide docs page [1], which lists our guidance on best practices and patterns for using Redux.

I also just published a brand-new "Redux Essentials" core docs tutorial [2], which teaches "how to use Redux, the right way", using our latest recommended tools and practices like Redux Toolkit and the React-Redux hooks API.

We unfortunately can't wave a magic wand and get folks to update the seemingly endless parade of Medium tutorials and Youtube videos that show the older approaches to using Redux, but I'm hopeful that the emphasis on using RTK will make it a lot easier for folks to learn and use Redux going forward.

[0] https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-ta...

[1] https://blog.isquaredsoftware.com/2019/10/redux-starter-kit-...

[2] https://redux-toolkit.js.org

[3] https://redux.js.org/style-guide/style-guide

[4] https://redux.js.org/tutorials/essentials/part-1-overview-co...

You certainly have more experience and context than me. But my experience with Redux over the years is there was so many ways to do it leading to a lot of uncertainty. Do you use a switch statement or something like redux-actions? Do you use the duck pattern, where do all these things live in the codebase? What package do you grab for async actions? Are actions 1:1 with DOM events, or are they more like a state machine? How do you compose reducers? Should you compose reducers?

I think this led to a lot of confusion and uncertainty with Redux. "I'm using it, but I'm not sure I'm using it effectively." I think a lot of ineffective implementations caused a lot of developers to get a really bad taste. I can unfortunately say at my previous company, just mentioning Redux would make just about every developer cringe. I hated that.

But I feel like a lot of what is making Redux more successful these days is the more opinionated releases like the toolkit and the new docs. Since they've only been around about a year now, I think it's reasonable to conclude that before their existence, Redux didn't have a strong opinion a new developer could lean on.

It's similar to React, which also tries to avoid opinions. I can appreciate and understand that approach (for both React and Redux), but I do wonder would React be better if there was a stronger opinion on things like CSS, routing, state, etc?

I don't mean to criticize. I love Redux and am very grateful for it. This is just how I experienced it over the years.

I think the biggest problem is the default approach of using thunks for handling async state. You get these "opinionated" frameworks that then reinforce terrible design ideas.

If it's simple just put handle async stuff in situ. If it's more complex, use custom middleware. Thunks, sagas, etc are all anti-patterns. The single worst thing the Redux docs did was give the impression that middleware was some kind of advanced functionality only useful for library designers. Most of your app logic should probably live in middleware.

The "redux toolkit" or whatever doesn't help with that, it only reifies questionable practices. Skip it. Write a simple utility for generating actions/types, and then go about your business.