
Redux – Not Dead Yet (2018) - dabj
https://blog.isquaredsoftware.com/2018/03/redux-not-dead-yet/
======
sktrdie
One underrated thing that I miss from using Redux is the "action trace". You
can literally sit down with the stakeholders [1] and explain the _exact things
that caused a screen to render_. And these things are not cryptic function
calls with stack-traces, but simple and chronologically ordered sets of human
readable "actions" (I like to think of them as events) like UserFetched ->
PlanFetched (<with this data>) -> FrozenUser. One can rewind the actions and
iterate with the stakeholders _why_ that screen appeared. This is huge and I
miss this a lot.

1\. Note that most of the time the stakeholder is yourself and/or another
developer. But can also definitely be a non-coder.

~~~
petilon
Overrated. In what kind of application do you need this? In the vast majority
of React apps you do not need this.

~~~
onion2k
_In the vast majority of React apps you do not need this._

I work on an app that has a total of about 400 separate Redux actions across
half a dozen reducers and a couple of stores. There's _a lot_ of things that
cause side effects. Being about to see what actions fired with various props
is immensely useful for debugging. redux-devtools and Reactotron are immensely
useful. You're right that the majority of React apps don't need to trace
actions, but when you do you definitely won't think it's overrated.

~~~
runawaybottle
Can you give me an example how you got to 400 actions? Just enumerate like 5
or so, I’m assuming you are building features where groups of actions are just
necessary based on the patterns you are using.

I’m genuinely curious because I feel like this kind of inflation of
actions/reducers in Redux is what makes it nightmarish.

~~~
jfengel
For one thing they do encourage a lot of tiny actions. A frequent pattern I
use requires three actions for every server call: one to trigger a saga, one
when it succeeds, and one for when it fails.

The standard form is incredibly verbose, I've started to shift away from it.

~~~
acemarke
Note that the new `createAsyncThunk` API in Redux Toolkit handles generating
and dispatching the promise lifecycle actions for you [0]. Also, while sagas
are a great power tool, most Redux apps don't need them [1].

[0] [https://redux-toolkit.js.org/api/createAsyncThunk](https://redux-
toolkit.js.org/api/createAsyncThunk)

[1] [https://blog.isquaredsoftware.com/2020/02/blogged-answers-
wh...](https://blog.isquaredsoftware.com/2020/02/blogged-answers-why-redux-
toolkit-uses-thunks-for-async-logic/)

~~~
mikewhy
Awesome! It's great to finally have some links to share.

The company I'm currently working with is the first time I've used sagas /
observables / "anything async is through side effects". I've constantly been
saying "this is madness, this giant block of code, all these concepts, all
this room for things to go wrong, just to do a `fetch`?". It's also the first
time in a few years of using redux I've had to deal with race conditions.

Edit: Oh, and you can even `await dispatch`! All the things I've been doing in
Redux for years and told I shouldn't, now being officially endorsed.

------
acemarke
Oh hey, that's my post.

I first wrote it back in 2018, and just updated it yesterday with some
additional links and comparisons.

(Actually was considering retitling it after getting some feedback last night,
but given that the link just got submitted here, I'll leave it as-is for now.)

A few quick notes:

\- If you haven't looked at Redux in a while, please try out our official
Redux Toolkit package [0], which is now our recommended approach for writing
Redux logic, and the React-Redux hooks API [1]. We're going to be teaching
both of those as the default approach for using Redux going forward.

\- We have a new "Style Guide" docs page that gives our official guidance on
suggested usage patterns [2]

\- On that note, I'm working on an ongoing major rewrite of the Redux core
docs [3]. My current task is creating a new "Quick Start" tutorial, which will
be a "top-down" intro to using Redux to stand alongside the existing "bottom-
up" tutorial sequence. The goal of the Quick Start section is to quickly
introduce Redux concepts, and show RTK and hooks as the "right way to write
Redux code", without going into the details of how it works under the hood, so
that folks can get started now and learn the underlying aspects later. I've an
early partial WIP draft PR up [4], and hope to finish the first draft in the
next few days. Once the Quick Start page is done, I'll be turning my attention
to rewriting the main tutorial sequence in order to remove outdated terms,
clarify explanations, and teach simpler patterns (like using "ducks" files
instead of splitting code across multiple files).

If anyone's got questions on anything I wrote in the article or otherwise
Redux-related, ask away!

[0] [https://redux-toolkit.js.org](https://redux-toolkit.js.org)

[1] [https://react-redux.js.org/api/hooks](https://react-
redux.js.org/api/hooks)

[2] [https://redux.js.org/style-guide/style-guide](https://redux.js.org/style-
guide/style-guide)

[3]
[https://github.com/reduxjs/redux/issues/3592](https://github.com/reduxjs/redux/issues/3592)

[4]
[https://github.com/reduxjs/redux/pull/3740](https://github.com/reduxjs/redux/pull/3740)

~~~
thekemkid
Do you, or anyone else in the team or community, have a good resource you
would recommend to people complaining about "too much boilerplate" in redux
code? It is likely the most common complaint I see, that I understand to come
from a place of people not understanding it this a tool best used for
_scaling_ and/or already _big_ projects. Whenever I have worked with Redux in
a large project, that "boilerplate" is minimal and the benefits obvious.

~~~
Scarblac
I think that complaint usually comes from people who try to put _everything
related to state_ in Redux, and not just the parts of it that need to be.

Also the 'reducks' pattern of splitting the Redux state into separate files,
each containing a reducer and the related actions and selectors helps keep
things simple to understand (although I guess it is a bit more overhead,
actually).

~~~
runawaybottle
I’ve read articles about how the Ducks pattern in practice also become
untenable.

------
cameronfraser
I found I was just using Redux as a data caching layer and ended up using SWR
hooks instead [https://swr.now.sh/](https://swr.now.sh/). This has resulted in
way less boilerplate (which increases even more with a type system) and a
better development and user experience for the product I was working on. For
everything else I use context like managing modals, auth, errors, and firebase
connections.

------
vikingcaffiene
I love Redux but I am very frugal about what I put into the store and have
come up with a strong set of design patterns with my team to know what should
and should not go there. That, in conjunction with hooks for any other
stateful concerns we have, makes for a sane and pleasant dev experience.

IMO the biggest and best draw of Redux is how it allows you to completely
separate your business logic from your UI layers. Your components only know
about props and state and are rather trivial to test. Hooks are great for re-
usable logic as well but my team made the choice to have hooks deal only with
localized state concerns and have a robust Actions => Services => Reducer
layer for everything that speaks to things outside that constraint. Its worked
out wonderfully so far. Tests are a breeze and logic is highly portable. Our
UI layer is thin and easy to change.

Its not all roses of course. The Redux store can turn into a rats nest of keys
and values with no obvious structure (or worse, duplicated structures). It's
something that requires actually sitting down and modelling out your data
structures. Sadly that's something I don't see very often (and I am just as
guilty as anyone else). The Redux team came up with some good guidelines on
this point (too lazy to track the link down but its on the main site) and I
think they have some really good ideas. I think more than anything its
important to consider your store in the same manner you would a database and
approach it with that kind of mindset. As with all things JS, its easy to dive
in, hard to untangle yourself! :)

~~~
bugeats
> I think more than anything its important to consider your store in the same
> manner you would a database

Yes and to keep it normalized. IMO, Redux is incomplete without some sort of
selector layer, which acts as the metaphorical database views.

[https://github.com/reduxjs/reselect](https://github.com/reduxjs/reselect)

~~~
acemarke
We've recommended normalizing data as a pattern for years [0], but never had
any official tooling to support that use case. Redux Toolkit 1.3 now has a new
`createEntityAdapter` API that can help with the process of inserting and
updating normalized data [1].

[0] [https://redux.js.org/recipes/structuring-
reducers/normalizin...](https://redux.js.org/recipes/structuring-
reducers/normalizing-state-shape)

[1] [https://redux-toolkit.js.org/api/createEntityAdapter](https://redux-
toolkit.js.org/api/createEntityAdapter)

------
Justsignedup
So many great things about redux that are hard to mimic...

\- the ability to create a middleware that is your analytics listeners.
Analytics will listen to actions and spit out analytic info when those actions
trigger. Because of this there is literally no analytics code anywhere in your
codebase, except encapsulated in that one analytics middleware and sub-tree.

\- Ability to just see every state update in dev tools which is AMAZING for
tracking down what caused a non-obvious problem. For example: Was it a bad api
request? Was it a bug in the reducer? etc. Hard problems suddenly become
easier with good debugging tools.

\- Ability to persist a part of the store to local storage. This is actually
quite nice.

~~~
karatestomp
One thing I like is that it's really easy to put a client library (for, say,
some REST service) behind a combine-reducerable Redux store and a few exposed
"action creators" (event emitters). Especially if you're using TypeScript so
all that stuff's easy to find and understand. Anyone familiar with Redux will
be able to use it immediately, and it'll work just fine anywhere JavaScript
does (provided whatever other packages the client lib depends on will work on
a given platform) including places you might want, for good reasons, to use
JavaScript but lean on some UI system other than React (Apple TV, say, or
maybe Electron).

------
runawaybottle
I don’t like the structure Redux forces my apps into. This might be a good
opportunity to see what simple solutions people are using to avoid stuff like
Redux. I remember reading about this:

[https://hookstate.js.org/](https://hookstate.js.org/)

~~~
petargyurov
I am inclined to agree. At first I thought Redux was awesome, but eventually
discovered that there is a lot of boilerplate and just a general overhead to
doing certain things.

However, I definitely fall into the cluster of people that were "just told to
use Redux". For my next React project I will certainly evaluate other
approaches.

------
abhisuri97
I taught a course on Javascript in undergrad with a unit on react as well as
redux (cis.upenn.edu/~cis197, check it out!). To this day, I still think
people learning JS should know about redux because of the design pattern it
encourages (note that when people are first learning CS, this is probably the
first-ish time they're coming across the concept of a reducer and "functional"
state that isn't mutated directly).

I think it's even more important for people self-learning react to be exposed
to redux in some way; yeah, there's boilerplate, but it's just beautiful when
all put together and isn't a Blackbox (I love dan's tutorial on egghead
explaining redux from the ground up precisely because it breaks down exactly
what's working and why it is).

This blog post does an excellent job of convincing newcomers in the JS world
to consider learning redux. I'm definitely forwarding this to the current
instructor of the course!

------
warp
I've recently tried using Redux for a side-project. While it solves the
problem (organizing state), I feel there is too much boilerplate for my small
project.

Are there any popular alternatives which don't use reducers?

EDIT: thanks for all the responses, I'll check them out :)

~~~
tarcon
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.

~~~
bufferoverflow
I've done that recently, and I had many performance issues. I have a long-ish
list of very simple components that are in a sorted order. So when I change
the value of one, I re-sort the list. I was hoping React would only rerender
the changed items (remove old, insert new). But no, it rerenders the whole
list, which takes 500ms. I made sure object references in the list stay the
same, that didn't help.

I can implement this thing in vanilla JS, and it would not take more than a
few milliseconds. React is cool, but so damn hard to optimize.

~~~
acemarke
It's important to distinguish between React "rendering" (asking components
what they want the UI to look like), and actually applying updates to the DOM.

React's default behavior is that when a component renders, React will
recursively re-render _all_ of its descendants. it then diffs the VDOM render
output to see if you've asked for any changes to the UI since the last time it
updated. If the two VDOM trees are the same, React says "nope, nothing to do
here!", and ends the render pass. _If_ you requested changes, it then gathers
them up and applies them all to the DOM in one step.

You can optimize the rendering behavior in some ways if needed. The
`React.memo()`, `PureComponent`, and `shouldComponentUpdate` APIs [0] allow
you to tell React to skip re-rendering if you know that a component's props
haven't meaningfully changed, and thus would result in the same UI output as
the last time. This does require that the child components be separate
component types (ie, `<MyComponent />`), not just the parent rendering a bunch
of plain elements (like `<div>`).

For lists in particular, React needs to know how to identify which items are
which. React doesn't care about object references, but you can pass a special
prop called a `key` when rendering items in a list. That way, if you move a
list item up, swap a couple others, delete one, and add a couple more, React
knows what existing list items ended up where, and can update the DOM
efficiently in response. Otherwise, changes to lists without good use of keys
can result in more DOM work being done than actually necessary.

[0] [https://reactjs.org/docs/react-
api.html#reactmemo](https://reactjs.org/docs/react-api.html#reactmemo)

[1] [https://reactjs.org/docs/lists-and-
keys.html](https://reactjs.org/docs/lists-and-keys.html)

------
RedBeetDeadpool
I agree ... I recently went back to using Redux in a project and I'm loving
it. Redux at its heart is just a state manager, but because people tie it to
React I've gotten people tell me all sorts things about how you don't need it
anymore with all its new features.

I think the addition of React's hooks and context api actually make Redux
easier to use, and I like the purity of its role as a state manager. I
personally find that its cleaner to keep the overall application state in
redux than to hold onto it inside of React, and leave react to manage its own
component's state regarding ui level interactions.

------
izolate
I don't like how this article moves the goal posts of whether redux fits our
use case or not. It has some valid arguments (dev tools) but the overhead of
the boilerplate and tooling around redux is just not worth it IMO.

Much better to break your app state into various custom hooks that leverage
Context API and the `useReducer` hook.

~~~
acemarke
Not sure what you mean by "moving the goalposts" here.

I'm trying to make a few specific points:

\- Redux is not "dead" in the sense that it is still widely used and is
continuing to be adopted

\- There are definitely many other tools in the React ecosystem that overlap
with how you'd use Redux, but the Venn diagrams for the use cases don't
entirely match up, and the other solutions don't necessarily have all the
capabilities of Redux

\- Redux _has_ been over-used and put in apps where it didn't fit well, and I
want people to only use it when it makes sense to do so

\- Our Redux Toolkit library and React-Redux hooks API make it a lot easier to
use Redux

~~~
runawaybottle
A lot of the pushback is coming from this:

‘ - Redux _has_ been over-used and put in apps where it didn't fit well, and I
want people to only use it when it makes sense to do so’. ‘

There are developers working day in and day out in these Redux codebases so
our feedback is coming from a real place. There’s a million articles that
pushed Redux to the top and got it used in just about everything. Articles
just like this one.

This article is literally pushing back against all the reasons why Redux might
not be a good fit. There’s very little in it that goes ‘yeah you know what,
for this scenario, don’t use Redux’.

~~~
acemarke
That's because:

\- I have no control over the millions of other tutorials that have been
written. I can only control my own blog, and the actual Redux docs.

\- The question of "When does it make sense to use Redux?" has been answered
numerous times already [0] [1] [2]

\- I wasn't trying to address the "when?" question in this article. I was
trying to answer "is Redux still a viable choice, and how does it compare to
other alternatives?"

I've written plenty of 6-10K word blog posts about Redux before that delve
into how and when to use it. That wasn't my goal for this post.

[0] [https://medium.com/@dan_abramov/you-might-not-need-redux-
be4...](https://medium.com/@dan_abramov/you-might-not-need-redux-be46360cf367)

[1] [https://redux.js.org/faq/general#when-should-i-use-
redux](https://redux.js.org/faq/general#when-should-i-use-redux)

[2] [https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-
ta...](https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao-of-redux-
part-1/)

~~~
rendall
There is an odd dynamic that happens in tech: A framework or approach exists
for a specific purpose; that framework is used badly or inappropriately by
devs who don't fully understand it; those same devs spread the idea that said
framework is bad/difficult/insecure and people who use it just don't know what
they're doing; some of those devs happen to be "thought leaders" and use their
platform to broadcast their misunderstanding as gospel

CSS, SASS, redux, array.reduce, webpack are examples that come immediately to
mind from the javascript world. There have been so many throughout the years

~~~
runawaybottle
So it’s difficult to parse what your observation is providing insight into.

So let’s see how this blame game works, because I have a hunch you want to aim
it at people that think Redux is a bad choice.

You are suggesting that people that really don’t like Redux actually don’t
know how to use it properly, misuse it, go down that rabbit hole and come out
completely jaded by it. They then go on to provide their feedback, to which
the obvious dismissive response is ‘well maybe you don’t know what your’re
doing’. So the bad mouthing is actually occurring from the other side, no?

For the last few years, any job post you saw related to React, Redux was a
prerequisite for probably over 90% of those posts. In other words, Redux was
gospel, not the the feedback of naysayers. The mass broadcasting was happening
by the framework adopters to the point said framework became ubiquitous.

Lastly, there’s very little feedback about Redux that has to do with people’s
understanding of it. Almost the entirety of feedback is coming from usage of
Redux and noticing by-products of using it (bloated code base, needless
complexity - and this needless complexity criticism is ripe for being sniped
by the framework advocates as a symptom of essentially incompetent developers
who can’t see the elegance of Redux. The feedback is that it’s not elegant ).

The thought leaders are not the people providing negative feedback in this
thread and elsewhere. The thought leaders, the gospel creators in this case
are these Redux based articles/advocates that prolifically spread Redux
throughout the React ecosystem to the point it became a standard dependency
for every app.

In this case, this is a very real situation where it needs serious push back
because it spread untethered and unexamined.

One thing I also want to point out, the same way the developer community has a
responsibility to evaluate the proper usage of a technology, those who partake
in pushing certain technology also have a responsibility of analyzing the
impact of what they are evangelizing. One could argue it is irresponsible for
influential subsets of the Javascript ecosystem to push a layer of complexity
for apps that do not need to make the trade offs for a few features.

~~~
rendall
@runawaybottle, with sincere respect, you projected a lot of meaning into what
I wrote: "You are suggesting that people that really don’t like Redux actually
don’t know how to use it properly, misuse it, go down that rabbit hole and
come out completely jaded by it."

Nope. Neither implied nor intended.

The article is a reasonable reaction by a redux maintainer to the dynamic I
describe. "I don't like using Redux" is a totally valid opinion. "Redux is
terrible" is, frankly, not a valid opinion. Neither is it valid for CSS,
javascript, React, Vue, Pascal, COBOL nor what-have-you, and yet here we are
yet again, letting fickle winds of fashion and facile opinion dictate what
should be engineering decisions.

Use redux if your use case applies. Don't use redux if it doesn't. If you find
it unwieldy, dont use it. I wish the tech community could leave it there, but
they don't.

------
joekrill
Redux is great, and I'm glad to see all this cleared up, to some extent.
Especially the bit about the new context API somehow eliminating the need for
Redux. I know some people don't like redux and that's fine - don't use it. But
it's still super-useful to many, many people.

~~~
runawaybottle
We all don’t get to waltz into a new job and say ‘Hey remove all this verbose
Redux code and app structure, it’s slowing down velocity. Plus this crud app
is too simple to add this annoying layer of boilerplate’.

------
mharroun
Redux always had to much boilerplate for me to prefer it.

The last couple years I have been using the new Context API and spliting my
app state out by creating a global context, and many domain specific contexts
where the context contains both the data and functions used to work with that
data. Typescript + state with data and functions created a great api per
domain. I found this approach just as clean but with less boilerplate.

Though redux does have some performance and tooling benefits.

~~~
tracker1
I disagree... I use useSelector, and now all my actions.js files export a
default useActions method with a wrapper I wrote...

Yeah, the boilerplate setting up the middleware and initial reducer isn't
fun... but it's been really rewarding and the react-redux hook has been a
godsend.

[https://www.npmjs.com/package/react-redux-actions-
hook](https://www.npmjs.com/package/react-redux-actions-hook)

~~~
acemarke
Note that with Redux Toolkit, that store setup is now a single line:

    
    
        const store = configureStore({reducer: rootReducer})
    

[https://redux-toolkit.js.org/usage/usage-
guide#simplifying-s...](https://redux-toolkit.js.org/usage/usage-
guide#simplifying-store-setup-with-configurestore)

~~~
tracker1
Cool, but I tend to use sessionStorage as a backup to the store to re-hydrate
on reload... I also use the thunks plugin so that I can have actioncreators
that do multiple dispatches.

~~~
acemarke
Right, and `configureStore` automatically adds the thunk middleware by default
[0], as well as the Redux DevTools extension.

You'd still have to pass in options for whatever persistence addon you want to
use, but that would be something like:

    
    
        const store = configureStore({
            reducer: rootReducer,
            middleware: [...getDefaultMiddleware(), myPersistenceMiddleware]
        })
    

Which is still shorter and easier to read than having to mess with
`applyMiddleware` and `compose` yourself.

[0] [https://redux-
toolkit.js.org/api/getDefaultMiddleware#includ...](https://redux-
toolkit.js.org/api/getDefaultMiddleware#included-default-middleware)

------
sergiotapia
The most overrated tool I've ever had to misfortune of having to wrangle. Talk
about bloat and lasagna code.

I've used mobx and it's better. Now I use apollo, and it's even better.

Just thinking about having to use redux and sagas and all that bloat makes my
stress levels rise. I can't believe it became as big as it did.

"muh time travel" is a meme of epic proportions.

~~~
mosdl
Amazing how many downvotes all the redux critical posts get. Redux is indeed
horrible and leads to all sorts of bloat and bugs.

~~~
sergiotapia
Sunk cost, these people have spent hundreds of hours learning something that
ultimately is going to be discarded even more. That's why people are
downvoting.

~~~
lghh
No, I downvoted because all the comments amount to X bad Y good. What they are
posting has nothing to do with the article. The article even specifically
talks about most of the Ys that are getting commented about and address what
use-cases they are for that Redux isn't for. It's clear those people are not
here to talk about the thing they are commenting on, they are just here to
tell everyone they don't like Redux.

~~~
mosdl
I have yet to be given a good usecase for Redux. All I see is code that ends
up causing issues:

\- redux pollution (not cleaning up state and things leaking)

\- because you can't access redux state directly, components have to copy
redux state and store them as props (which makes 0 sense, its state not
props). But now you run into the issue where the local prop is not in sync
with redux since redux updates are correctly done in chunks.

~~~
acemarke
What do you mean by "can't access Redux state directly" and "copy Redux
state"? Neither of those sounds correct.

Components have always been able to extract whatever data they want from the
store using the `connect` API, and now our new `useSelector` hook. Those APIs
return whatever values _you_ want for use in the component, and that generally
is the actual object references to the real data that's in the store.

Both `connect` and `useSelector` subscribe to the store and re-run the logic
you've provided whenever the store is updated, and force a re-render of your
component with that fresh data. If I have:

    
    
        const user = useSelector( state => state.users.entities[props.userId])
    

Any update to that specific `user` object in the store will cause this
component to re-render. Same goes for `connect` and `mapState`.

So yeah, your statement confuses me, because it doesn't seem to describe how
React-Redux actually works.

~~~
mosdl
Most redux users use mapStateToProps and rely on it to notify you when a redux
change has happened.

~~~
acemarke
Right, and I'm saying that both `mapState` and `useSelector` perform the same
behavior: allowing your component to subscribe to portions of the Redux store
state, extract that, and update the component when that data changes.

So, I don't understand what points your parent comment is trying to make,
because the whole point of React-Redux _is_ to keep your components in sync
with the data in the Redux store state.

~~~
mosdl
We have run into several issues where a user clicks a button (which updates
redux) and then quickly clicks on something else and the 2nd component has not
been updated yet as it used the mapState prop (the update is being batched by
redux and hasn't gone out yet to the listeners).

Switched to using a shared model class instance - the value is changed
immediately and anyone who needs to know the latest version can do it easily.
Much simpler, faster and easier to debug since there is truly only one source
of truth, not copies everywhere.

~~~
acemarke
That sounds very surprising. Yes, React-Redux does batching and cascades
updates through the UI layer, but that process should happen extremely quickly
(far faster than the amount of time needed for someone to click on another
button).

I'm also not sure why you keep using the phrase "copies". The Redux store has
the only actual copy of that data, and your `mapState/useSelector` functions
typically return the actual references to that same data. The only copies made
are if you make them yourself. Also, the value in the store _is_ already
updated before any of the UI subscribers are notified.

Can you put together a sandbox that reproduces this problem and file an issue?
I'm very curious what you're actually seeing.

~~~
mosdl
Pretty easy - component that stores a redux computed value and a setTimeout
that calls an action with the value. If the settimeout (or a websocket event,
etc) fires before the batched update, you are out of sync.

Most people have simple applications so redux works fine, but once you get
complicated async work things just break down.

~~~
acemarke
tbh that doesn't sound like a Redux-specific problem. That sounds like a
general async / stale-references problem. If you've captured a value and try
to use it later, then yeah, you're probably going not going to be using the
latest version.

~~~
mosdl
Which is a design flaw of redux. Proper systems allow you to access the
current state value at all times, without having to worry about batching.

------
markandrewj
I find the hook API cleaner for most common use cases. It is also better for
things like forms, which redux wasn't intended for.

[https://redux.js.org/faq/organizing-state#should-i-put-
form-...](https://redux.js.org/faq/organizing-state#should-i-put-form-state-
or-other-ui-state-in-my-store)

------
yatsyk
I can’t justify redux usage apart from legacy support. Mobx (preferred) or
hooks for some apps/components.

------
techsin101
I like redux but what could be achieved with an a tag and another HTML page
now needs 700 lines of code due too react, redux, webpack, router, server
rendering, partial loading.................................................
Yeah I don't want to make my life harder for no reason

------
gbourne
I've used redux many times and the amount of boilerplate code is large. What
Redux does is cool, but it complicates the app and is a pain to update. I feel
this is going to go the way of Java Enterprise Beans as React continues to
mature.

------
daenz
That quote "if you're explaining, you're losing" applies here.

~~~
acemarke
Trying to clarify FUD on the internet is certainly a fool's errand, but at
least I've got a writeup to link to when I see people ask these questions.

------
dprai
[https://cerebraljs.com/](https://cerebraljs.com/)

------
aerovistae
Worth noting this is from 2018...

~~~
acemarke
As I noted at the start of the post, I updated it literally yesterday with
some additional information and links and then tweeted about it, which is why
someone else apparently decided to submit it today.

------
tren-hard
> Is Redux dead, dying, deprecated, or about to be replaced? No.

Reading through the comments it sounds like it's struggling, even positing the
question sews doubt. I thought redux was still one of the 'must have' tools
for building react apps now.

What has everyone been migrating to? Is there a consensus successor to Redux?

~~~
tmountain
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.

3) The new React "Hooks" API

Looks nice. Have not used it.

------
ChrisArchitect
previous comments, when this may have actually been news:
[https://news.ycombinator.com/item?id=16918003](https://news.ycombinator.com/item?id=16918003)

why post it again?

~~~
acemarke
I updated the post yesterday with new links and information, and tweeted a
mention of having done that. Apparently someone thought it was worth
submitting.

(tbh I'd forgotten it actually hit the front of HN when I wrote it the first
time!)

------
rileytg
i propose updating the title to include something about this being (revised
04-2020) or [updated]

i’ve been wondering the state of things as im jumping back into react projects
after a couple years off.

------
PaulHoule
Four letters: V, U, E, X.

~~~
jxub
Or MobX which is also neat.

------
stillbourne
I really think it should die, from a DDD perspective EDA should be handled as
backend tasks with CQRS. If your api server isn't handling that then you
really should stand up a BFF. I get that Redux is designed to handle all of
that on the front end but it just doesn't belong there. I have seen too many
projects devolve into garbage because they are trying to shoehorn too much
crap into reducer patterns when it just doesn't belong there.

~~~
imbusy111
How do you update the front-end state after the backend task is complete other
than reload the whole page?

~~~
stillbourne
websockets or any stream service such as kafka

