
Reasons to Learn Redux as a JavaScript Developer - fagnerbrack
https://www.robinwieruch.de/redux-javascript
======
acemarke
I'm a Redux maintainer. I agree with the points Robin made, and want to toss
out a few additional bits of info.

There's been a lot of chatter on social media over the last couple years
suggesting Redux is dying or no longer needed. While it's true that there's a
number of other options available, and that there's not as much _need_ to use
Redux right away as there used to be, there's still plenty of good reasons to
use Redux. In addition, Redux continues to be very widely used, and I've seen
quite a few major apps choose to use it over the last year. I talked about
these aspects in my Reactathon 2019 talk on "The State of Redux" [0] and my
post "Redux - Not Dead Yet!" [1].

We recently released a new official package called Redux Toolkit [2], which
includes utilities to simplify several common Redux use cases, including store
setup, defining reducers, immutable update logic, and even creating entire
"slices" of state at once. It's now our recommended approach for writing Redux
logic. It's also written in TypeScript, and the API is designed to provide a
great experience in TS apps.

We're currently working on an ongoing major rewrite of the Redux core docs
[3], which has several goals: updating content to better match today's target
dev audience (removing references to "Flux", etc), simplifying explanations,
encouraging easier patterns, and adding additional content and guidance on
real-world usage.

As part of that, we've added a new "Style Guide" page [4], which has our
recommended patterns and practices for writing good Redux code. We're
specifically emphasizing and recommending patterns that simplify the amount of
code you have to write, like using Immer for immutable updates, using the
"ducks" structure for files and logic, treating actions as "events" rather
than "setters", and so on.

Earlier this year, we also released new versions of React-Redux. v7.0 was a
complete rewrite of the internals to improve performance, and v7.1 added a new
React hooks API [5] as an alternative to the classic `connect()` API.

If you're interested in some of the behind-the-scenes details on how these
libraries have evolved, see my posts "The History and Implementation of React-
Redux" [5] and "Redux Toolkit 1.0" [6].

If anyone's got any questions, ask away!

[0] [https://blog.isquaredsoftware.com/2019/03/presentation-
state...](https://blog.isquaredsoftware.com/2019/03/presentation-state-of-
redux/)

[1] [https://blog.isquaredsoftware.com/2018/03/redux-not-dead-
yet...](https://blog.isquaredsoftware.com/2018/03/redux-not-dead-yet/)

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

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

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

[5] [https://blog.isquaredsoftware.com/2018/11/react-redux-
histor...](https://blog.isquaredsoftware.com/2018/11/react-redux-history-
implementation/)

[6] [https://blog.isquaredsoftware.com/2019/10/redux-starter-
kit-...](https://blog.isquaredsoftware.com/2019/10/redux-starter-kit-1.0/)

~~~
weeksie
This is disappointing. Partially for bikeshed reasons, but also for practical
ones. Redux thunk is an anti pattern as far as I'm concerned but you're
including it by default? Why? Just because it's the first (bad) decision
people make when trying to handle async code doesn't mean it's the one that
should be canonized.

The createAction function is unnecessarily verbose and the createReducer
function obscures more than it abstracts.

~~~
acemarke
I find your concerns very confusing.

In order:

Thunks are the most widely used middleware by a large margin [0], and we have
frequently received complaints that there is no async middleware included in
the Redux store by default. Thunks were in fact part of the store during the
original development phase [1], but were made separate once the middleware API
was defined [2]. Thunks are effectively the minimum viable way to write async
logic that has access to interacting with the Redux store, so we include that
in RTK out of the box to make that possible.

Sagas, observables, and other similar middleware are far too heavyweight and
complex for us to endorse as the default async approach. I also strongly
disagree that thunks are an "anti-pattern", and find them to be a highly
useful tool (and especially so now that `async/await` syntax makes it even
easier to write more complicated async logic in a readable form) [3].

You are always welcome to add another middleware or disable thunks as part of
the store setup process instead if you want.

I don't see how this:

    
    
        const addTodo = createAction("todos/add")
    

is more verbose than this:

    
    
        const addTodo = (text) => {
            return {
                type: "todos/add",
                payload: text
            }
        }
    

We've had a version of `createReducer` shown in the "Reducing Boilerplate"
docs page [4] for years, and there are literally hundreds of similar "lookup
table"-type utilities out there. Including this in RTK is a no-brainer. It's
even more valuable, because ours uses Immer inside to let you write "mutative"
immutable update logic instead of having to nest spread operators. I don't see
how this is "obscuring" anything.

Finally, our recommendation is that most of the time you shouldn't even be
calling `createAction` and `createReducer` yourself. Instead, you should be
using the `createSlice` function [5], which automatically generates action
creators and action types for you, and calls the other two functions
internally.

[0] Slide 38 in [https://blog.isquaredsoftware.com/2017/09/presentation-
might...](https://blog.isquaredsoftware.com/2017/09/presentation-might-need-
redux-ecosystem/)

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

[2]
[https://github.com/reduxjs/redux/pull/63#issuecomment-110575...](https://github.com/reduxjs/redux/pull/63#issuecomment-110575809)

[3] [https://blog.isquaredsoftware.com/2017/01/idiomatic-redux-
th...](https://blog.isquaredsoftware.com/2017/01/idiomatic-redux-thoughts-on-
thunks-sagas-abstraction-and-reusability/)

[4] [https://redux.js.org/recipes/reducing-
boilerplate#generating...](https://redux.js.org/recipes/reducing-
boilerplate#generating-reducers)

[5] [https://redux-toolkit.js.org/api/createSlice](https://redux-
toolkit.js.org/api/createSlice)

~~~
jonreem
Thunk is not a proper solution to the problem - it's a totally open escape
hatch! You lose ALL the nice guarantees and behavior of redux when "action" no
longer means "immutable, serializable event" and starts meaning "completely
arbitrary function call with unbounded async effects."

There's no functional difference between using redux-thunk and just calling a
"global" `dispatch` in random callbacks; both are equally unmaintainable in
the face of interacting effects.

EDIT: Having a bunch of complex async logic all modifying your store in
overlapping ways without careful coordination is like having concurrent
operations on your database without any transactions or locking.

~~~
acemarke
Actions are _still_ always an "immutable serializable event". The async logic
is going to live _somewhere_, either in your components, or outside of them.
Thunks are a way to move that logic outside of your components. The end result
of the async logic is still dispatching plain object actions.

------
Karupan
Redux was such a mental overhead for me when I started out with it. The amount
of boilerplate code that I had to write for the project I worked on was very
frustrating. What helped me truly understand the concept was Elm.

These days I ask junior devs to learn Elm for a few days. We still use Redux,
I will not choose it for new projects.

~~~
freehunter
I see the Redux devs defending their tool in every comment thread around Redux
and I have to say to them: it's not your fault and there's not a lot you can
do to fix it by yourselves. The problem is every tutorial and training and
boot camp and video I've ever seen around Redux treats Redux like heavyweight
boilerplate and teaches you that you need five files with Redux where you only
needed one with plain React and every function you add needs to touch all five
of those files, including a file that only exists to write the name of the
function you've added.

What I hear from the Redux devs does not in any way line up with what I heard
from Brad Traversy or Stephen Grider, who have taught tens (hundreds?) of
thousands of people on Udemy that the simplest React projects _must_ be used
with Redux and Redux turns beautiful React code into dotcom-era Enterprise
Java.

~~~
acemarke
Yeah, unfortunately once something gets a large community, it takes on a life
of its own.

Part of the issue is that the Redux docs _do_ show many of these patterns
(`const ADD_TODO = "ADD_TODO"`, separate files and folders for constants /
actions / reducers, etc). Dan has said several times that he didn't expect
folks to literally mimic everything that was shown in the docs, but tbh that's
what people do. He's also said he wishes he'd emphasized teaching it in some
different ways.

We're doing everything we can to try to teach better practices and patterns
now, but that can't magically change the gazillions of existing tutorials and
codebases that are out there.

~~~
JMTQp8lwXL
> didn't expect folks to literally mimic everything that was shown in the docs

Isn't that the point of documentation? To give you a reasonable, suggested way
of incorporating a library into an existing project? This is almost saying,
"the docs were wrong and everyone learned the wrong thing". I don't think you
can blame package users for that. People reference documentation to know what
to do, and also what to avoid, when using a new library.

~~~
acemarke
Yeah, I know. I'm not blaming Dan here, specifically, just repeating what he's
said several times himself.

That's why we're doing the docs rewrite. The target audiences have changed
since 2015 (new devs learning Redux in a bootcamp vs folks coming from other
Flux libraries), we've got a better understanding of how Redux should be used,
and we want to set folks on a better path from the beginning.

------
sktrdie
The issue with Redux is that a dispatch() and hence a state update causes a
_synchronous_ (hence blocking) update of the view.

Andrew Clark better explains the difference in this tweet:
[https://twitter.com/acdlite/status/1195453776217296896](https://twitter.com/acdlite/status/1195453776217296896)

> Redux architecture depends on the ability to block the main thread until
> rendering is complete. Once you make rendering non-blocking, your store is
> no longer synchronized with the UI. Leading to data races and
> inconsistencies.

Many view layers are moving towards non-blocking rendering as they need to
account for things such as different priorities based on what the user needs:
for instance a user typing needs larger priority than a banner showing.

Once it is non-blocking it's hard to keep a store and several UIs elements in
sync. For instance your store might say isLoading:true but the UI might not
show that since it's rendering/working another higher-priority element on the
screen. And then you might have another view that depends on the
isLoading:true which causes another thing to appear on the screen before the
other element is shown... all this leads to inconsistencies and race
conditions.

Essentially the problem is that we have lots of code that does (especially in
thunks):

    
    
      store.dispatch(FOO)
      const state = store.getState() 
      // here we expect state to contain changes done by FOO
      // but with non-blocking UI this is no longer the case

~~~
acemarke
Andrew's not wrong, but I'm also not entirely convinced it's as big of a
concern as he's describing.

For context, Andrew is a co-creator of Redux, and is a current React core team
member. He's spent the last couple years working deeply on the "React Fiber"
rewrite that became 16.0, and the "Suspense" and "Concurrent Mode" features
that are now available in alpha.

He's definitely right that Redux's synchronous update model is somewhat
limited compared to how React's "Concurrent Mode" needs to be able to
dynamically re-order state updates based on priorities. But, it remains to be
seen how much of an actual problem this is in practice. Andrew's been heads-
down in this feature for a long time, and so it's natural that he's seeing
everything through that kind of a lens.

We've got an open issue to discuss and analyze how React-Redux might be able
to work better with CM and Suspense:

[https://github.com/reduxjs/react-
redux/issues/1351](https://github.com/reduxjs/react-redux/issues/1351)

------
sansnomme
Redux is tremendously verbose though. Message passing isn't attractive when
the state space is big.

~~~
acemarke
That's specifically why we've created our new official Redux Toolkit package -
to simplify the incidental complexity that is not actually part of Redux
itself. Try it for yourself :

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

------
leetrout
MobX does not get enough love and has been around for a while

[https://mobx.js.org/README.html](https://mobx.js.org/README.html)

~~~
Drdrdrq
MobX doesn't get enough hate either. Inexperienced devs will put everything in
the global state and end up with a soup. And, as opposed to Redux, it is
_magic_ - I would have trouble rewriting it from the docs, would you be able
to do it? Note that it also changes the way React render method works. All in
all - no thank you.

~~~
leetrout
Sloppy developers are sloppy in redux as well.

Vuex has a nice pattern with plugins and modules.

Mobx stands on its own outside of react. I understand many people don’t
consider redux outside of react and don’t talk about one without the other. As
other comments mentions the mobx state tree is more a drop in replacement for
redux. I am unfamiliar with the render method changes you reference- do you
have more info or a link?

~~~
Drdrdrq
> Sloppy developers are sloppy in redux as well.

Agreed. But the mess they make in MobX is in my experience much more difficult
to clean up.

What I meant with render method changes is that mobx tracks access to state
during a call to render (which means that anything that might influence
rendering, _must_ be accessed inside render). It seems like it's not a big
deal, but it can lead to surprising bugs if one is not careful. Redux otoh
uses props to pass data to render, which is much more explicit and allows
regular react dev tools to be used.

I might have some details wrong - I met MobX a year ago with two legacy apps
and it was a hell to maintain. Still is actually, I'm just not that involved
in these projects anymore. It's magic, and not in a good way. For new projects
we use Redux Toolkit, which strikes a nice balance between verbosity and being
explicit.

------
hnbreak
Redux is a mixed bag but I'd say it's one of the most elegant ways to handle
state.

Biggest problem and reason why people (me included at the beginning) don't
like Redux, you should know when you need it and you should use some
abstraction layer (eg RTK). One cause could be the docs: while the maintainer
try their best to educate a lot (also in this thread paired with interesting
link building strategies), there is not quick and easy way to get into Redux.
If you start with RTK's docs, you don't understand everything. Then, you need
to read the Redux docs, then again back and forth. And this just takes too
long to grok an actual simple API.

One easy indicator for Redux or not: does your app need kind of an undo
feature, then you should dive into Redux and I'll promise you. there is no
other way to do this in such a sane, maintainable way.

~~~
acemarke
As mentioned elsewhere in the thread, we're working on a major rewrite of the
Redux core docs. If you've got any specific suggestions on how we can improve
them, please let me know.

When you say "no quick and easy way to get started", are you referring to code
or docs?

In terms of explanations, RTK is currently documented as a separate layer on
top of Redux, because that's really what it is. So yes, we do assume that
folks have learned what Redux is and how to use it already, and RTK is then a
faster and better way to write Redux logic instead of doing everything "by
hand".

As part of the core docs rewrite, we do intend to completely redo the tutorial
sequence, and we'll be introducing RTK somewhere in the tutorials and
encouraging its use.

~~~
hnbreak
I meant the docs. It's like decades ago like when you wanted to learn Rails.
Then somebody said stop! First learn Ruby... This is not how people learn.
There's too much time between learning and trying, so there's no proper and
face-paced feedback loop. Let's try to get into somebody's head who's ok in
react and slowly wants to get into state management but having no clue of
nothing:

His mind:

\- Ok, where should I start?

\- Which is the best? Mobx, redux, just ContextProvider or local state??

 _The poor guys falls into the rabbit hole and reads Reddit, HN, Github issues
for hours, still not sure what to do; 2 hours later_

\- Ok, let's try redux, for whatever reason, the maintainers seem to be quite
active

 _The poor guy tries to decide if he should go just with redux /react-redux or
rtk; former because it is good to understand the foundation, latter good
because just to avoid boilerplate and that's what this acemark is promoting
everywhere. The guy is still overwhelmed and don't forget doing decision is
hard; it's one of the biggest struggles for humans_

\- Ok, I guess I need to start with redux because it's the foundation.

 _He sees all the theory, new terms, the boilerplate and there 's no fast-
paced feedback loop; he just think heck and checks out mobx, 4 hours later_

\- Man mobx is even more weird, totally unstructured and while mobx's
maintainer seems to be a nice guy, my gut feeling is: stay away

\- Let's check out npmtrends, oh great, npmtrends shows that people also don't
like mobx, cool, it has much less traction, decision made, nice

\- So, let's try redux again, maybe this time I start with RTK

 _We know what happens, RTK has better feedback loops but w /o the basic
knowledge of redux he will struggle, 6 hours later after jumping back and
forth the both docs_

\- Lets stop here, tomorrow is another day.

 _He is out of flow, motivation is down, the next day he doesn 't continue
because the whole experience didn't feel good, he writes a post on HN that
redux sucks steel and maybe looks the next week again on it_

The situation is a bit like with kubernetes; until you have proper feedback
loops with k8s you need days, with new k8s distros this got better but the
biggest bummer are the k8s docs, too much, too verbose, so many new terms, no
feedback loops at all and every k8s examples has minimum 100kb yamls.

What would be great and I know that writing good docs is much harder than
actual code:

One and only piece which the reader should read first, which teaches him redux
foundation, react-redux boilerplate and rtk within max 2 hours. After that he
should have a working example AND should have understood it. No links to other
resources, no nothing.

This main piece should be linked everywhere in the Github readmes of all redux
relates projects in bold and h1 READ OUR MAIN PIECE FIRST, on all the doc
pages and in all forum posts. I mean look at your post's footer in this
thread: so many links, why? You need one entry point. RTK could be the entry
point, it just needs a bit more flesh on redux and should be declared as the
entry point of redux. There's one disadvantage though: with RTK as entry you'd
kill the ecosystem around redux but IDK if you did this anyway by declaring
RTK the standard way. And you would have a lot of redundant docs with
redux/react-redux. Or maybe we need to merge all because maintaining redundant
docs is just too much for an OSS project.

Whatever, all not easy but there must be a way because redux is the most
underrated thing in the frontend world, it's def the best state management and
RTK is a nice and long deserved abstraction.

~~~
acemarke
Thanks for the feedback. I've pasted it into our "Docs Rewrite: Overview"
issue for reference [0].

Responding a bit further:

There's not much we can do about folks going back and forth between Redux and
various non-Redux-y things. That's outside of our scope and ability to help
with.

Teaching-wise, there's several reasons why the docs are structured the way
they are right now:

\- Redux itself is an independent library that is not tied to React in any way
(and is used with other frameworks / UI layers as well). Our docs do mostly
assume that you're using React, but the tutorials start out trying to show how
you'd use Redux without any UI layer, to teach the basic concepts.

\- React-Redux has been a separate library from Redux itself since it hit 1.0.
While we do teach the basics of how to use React-Redux in the Redux core docs,
it has its own separate repo and separate docs site. Similarly, RTK was
designed as an addon layer around the Redux core, so it also has a separate
repo and separate docs site, and its docs assume that you understand the
basics of Redux already.

\- That said, yes, the vast majority of Redux usage _is_ with React, and we
are encouraging folks to use RTK as the default way to write Redux logic. So,
it's very reasonable to have a docs page that shows how to jump right into
using both of them as fast as possible. This is something I've already said I
want to add to the docs, as a "Quick Start" page [1].

In terms of teaching flow and learning, there's various ways to approach
explaining things. Dan Abramov wrote the original Redux docs content and
structure, and his teaching style is very much "bottom-up, from first
principles". You can see that style in pages like the current "Middleware"
tutorial page [2], and his Redux videos on Egghead [3]. That approach works
great for some people, but other folks just want to be shown _how_ to do
something first, and learn the "why" later. It's hard to serve both groups at
the same time.

One issue with teaching RTK first is that while Redux requires / expects that
you use immutability correctly, RTK's use of Immer does hide the fact that
immutable updates are happening in the background. It would be easy for
someone who learns Redux via RTK to assume that writing mutating logic _is_
the right way to write reducers, not realize that it only works right due to
the "magic" inside RTK's APIs, and then go write reducers in another project
without RTK that are completely buggy as a result. I haven't yet entirely
figured out how to handle that aspect, other than plastering warning notes all
over the docs. That's one reason why I would prefer that folks understand the
core principles first and how to do things by hand, and then switch to RTK to
write the same code in simpler form.

As I said earlier, there's good reasons why we have separate libraries and
separate docs sites. I can hypothetically imagine pulling things together into
a combined docs site, similar to how NgRx does it [4]. But, I'm not sure how
technically feasible it would be. It might require restructuring everything
into a mono-repo, and I don't think I want to have to figure out how to
migrate everything at this point.

All that said, yes, part of the goals for this Redux core docs rewrite is to
provide a much more obvious learning path.

Finally, no, I don't think RTK is "killing the ecosystem around Redux", as the
ecosystem is much broader than what RTK includes. RTK does obsolete a lot of
similar libraries, but there's many other pieces out there for other use
cases.

[0]
[https://github.com/reduxjs/redux/issues/3592#issuecomment-57...](https://github.com/reduxjs/redux/issues/3592#issuecomment-570072854)

[1]
[https://github.com/reduxjs/redux/issues/3594](https://github.com/reduxjs/redux/issues/3594)

[2]
[https://redux.js.org/advanced/middleware](https://redux.js.org/advanced/middleware)

[3] [https://egghead.io/series/getting-started-with-
redux](https://egghead.io/series/getting-started-with-redux)

[4] [https://ngrx.io/docs](https://ngrx.io/docs)

~~~
hnbreak
Thanks for your reply. Man, so much legacy, now I get it better. The Quick
Start sounds like a good next step and some low hanging fruit!

ps and to understand your _That 's outside of our scope and ability to help
with._ better: Are you not also maintainer of redux and react-redux?

~~~
acemarke
Yes, I'm a Redux maintainer. My point is that I can't do anything to prevent
folks from asking "what state management approach should I use?", looking at
NPM trends, reading other tutorials that espouse differing approaches, or
jumping back and forth between the React, MobX, and Redux docs sites. All we
can do is try to provide as much helpful info in our own docs, and even that
assumes that folks even _read_ the Redux docs. I see a lot of people asking "I
want to learn $TOOL, what's the best course on Udemy?", and not even looking
at the actual docs for $TOOL at all. Doesn't matter how good the docs are if
people don't read them :(

------
gunn
Here's the library I wrote to replace redux for myself:
[https://github.com/gunn/pure-store](https://github.com/gunn/pure-store)

It's the simplest API I could think of, has excellent type support, and
handles immutability for you.

~~~
lioeters
Thank you for pure-store, I'm surprised it hasn't attracted more attention!

The API is perfectly small and straight-forward, it's close to the ideal I
imagine.

For a few years I've been using a similarly tiny library I wrote to reduce
Redux's verbosity, but I may migrate to pure-store as it's even smaller and
gets to the essence of state management.

Seeing the popularity of React hooks and Redux+friends, I know I'm in the
minority of people who lament the direction they're going. I'm secretly hoping
for a "destructuring" of the React ecosystem into more generic
concepts/libraries/modules that work with or without React, carrying on the
lessons learned but implemented as simple and independent as possible.

To me, pure-store (and immer for sure) is one of those libraries that point
the way to a better future.

------
robgibbons
This horse has already been beaten into a bloody pulp, but Redux is so
unnecessarily verbose. All due respect to the team behind it, but the DX of
Redux is just horrible. I can only imagine how many developers simply gave up
and became farmers because of Redux.

After being subjected to the "action types" modules full of redundantly named
constants, having to touch five files for a small feature, I simply use
Rematch now. Its API is like cake compared to Redux, while it still satisfies
the same underlying pattern for consistency/testability.

"I'm going to tell my kids that Rematch was Redux"

~~~
acemarke
As I've pointed to a number of times throughout this thread, we created our
new official Redux Toolkit package specifically to address those concerns:

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

In addition, our new Style Guide docs page recommends patterns that avoid
those issues as well, such as using the "ducks" file structure:

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

------
banachtarski
Anecdotally, Redux was absolutely awful to work with. Want a project chockful
of middleware to make it passably usable? Use Redux. With all due respect to
the Redux team, I simply don't think Redux scales in large applications. The
"defaults" are insanely unproductive and encourage developers to cram tons of
state in some global pile of state-soup just to claw back conveniences they
lost. Monadic transformers and pure state transitions - great ideas in
principle, carried way too far here in an ecosystem where the rest of the
language and libraries rely on and use mutable state. Not to mention the lost
performance, bloat for code that would be considerably shorter, and more
disadvantages.

No thanks Redux, no thanks :/

~~~
StuffedParrot
I was under the impression redux is basically a message bus plus some sugar.
Is that wrong?

~~~
tempsy
No you’re right. I find the comments deriding Redux as some bloated beast to
be amusing...it’s just a thing that lets you read and update a plain
javascript object that different parts of your app can access.

People making things more complicated than they are is really a disease in the
dev community.

~~~
banachtarski
> it’s just a thing that lets you read and update a plain javascript object
> that different parts of your app can access

Doesn't require a library, let alone an ecosystem of libraries.

~~~
lowtolerance
Why implement this functionality from scratch when a tried and tested
implementation exists.

~~~
TrinaryWorksToo
To eliminate a dependency.

~~~
nennes
So implementing everything from scratch has more benefits than a well
maintained and documented dependency?

~~~
TrinaryWorksToo
If it's simple, yeah. A redux-type store does not have to be complicated.
there are certainly performance optimizations to using redux versus rolling
your own, but that would only happen in very large applications.

~~~
nennes
I agree that you can roll your own store. You'll miss lot of free
functionality and the dev tools, but maybe it's not stuff you need.

I also agree that introducing a dependency at every opportunity comes with
serious drawbacks.

Every situation is unique of course. In my case: At work, I value code that is
more standardised so that I get less bugs, documentation / best patterns and
crucially easier on-boarding process. For a personal project, I would
definitely consider rolling out my own implementation, even just for the
learning it comes with.

~~~
TrinaryWorksToo
Yes, I agree. There are trade-offs to be considered. Those are definitely
benefits to using Redux, for sure.

------
csande17
Something I've wondered about the "immutable updates" pattern discussed in the
article: do JavaScript engines optimize it somehow? On its face, it seems like
it would turn a constant-time "favorite post X" operation into a linear-time
"create a copy of the array of all the posts, replacing post X with a copy of
post X where 'favorited' is true" operation.

Or do developers just assume that their UI code won't ever need to scale to
large numbers of items? (Is this why JIRA's web UI is so slow when you have a
couple thousand open tickets?)

~~~
fyp
Most functional languages have immutable persistent data structures that _don
't_ require a linear copy and are fairly efficient.

For example in clojure, sequences are implemented as 32-ary tries so
insert/delete/update to any particular index will only cost around sizeOfNode
* numParents=32 * log_32(n). This comes with a cost that indexing is now
log_32(n) but it's usually a fair price to pay.

In javascript, immutable.js implement these same ideas (as least according to
these talks where they talk about index tries and hash array mapped tries:
[https://youtu.be/I7IdS-PbEgI?t=456](https://youtu.be/I7IdS-PbEgI?t=456))

If you want native support, javascript engines are actually free to swap out
their implementation of arrays! I know they already do depending on whether
they think your array is sparse("holey") or not:
[https://github.com/v8/v8/blob/8.1.81/src/builtins/builtins-a...](https://github.com/v8/v8/blob/8.1.81/src/builtins/builtins-
array.cc#L887). I also vaguely recall someone saying that unshift (push to
front) is automatically optimized by switching to a deque/circular buffer but
I might be remembering wrong. Anyway, they _can_ make these optimizations in a
distant future but I don't think do today.

~~~
repsilat
> _Most functional languages have immutable persistent data structures that
> don 't require a linear copy and are fairly efficient._

This is true, but unfortunately those libraries/languages don't make use of
that tree structure for "partial memoization" of derived data. They very well
_could_ , but they don't -- even when you use Immutable.js in a Redux app, and
you use Reselect, your selectors will take linear time when you mutate one
element in an object/array instead of taking constant- or log-time.

~~~
fyp
Yea that's a good point. This matters when your derived data takes linear time
to recompute. There are still techniques to make this work (but not
automatically afaik). For example it's easy to make them efficient again if
your computation is just an associative fold or reversible fold: [https://sci-
hub.tw/https://link.springer.com/chapter/10.1007...](https://sci-
hub.tw/https://link.springer.com/chapter/10.1007/978-3-642-39038-8_29)

~~~
repsilat
That article talks about map and filter and fold, but I think there are also
(trickier) ways to make joins and sorts work as well.

I think it could be a great technique for a lot of things -- compilers and
database views, in addition to front-end state.

------
tempsy
Redux is not that hard to learn so why not?

Why spend more time debating whether to learn something than just learn it?

~~~
Supermancho
It's hard enough. I haven't needed it in developing/contributing to my own
frameworks and there's an infinite amount of things to look into. Right from
the Redux docs ([https://redux.js.org/faq/general/#when-should-i-use-
redux](https://redux.js.org/faq/general/#when-should-i-use-redux)) - the link
[https://gedd.ski/post/what-not-to-learn/](https://gedd.ski/post/what-not-to-
learn/)

~~~
tempsy
Dunno. Perhaps there’s more functionality than the core but all it is is a
plain JavaScript object that you “update” that you can access from different
parts of your app.

It really isn’t that complicated.

------
FpUser
My brain I guess works in a different way. I could never truly
understand/appreciate value of the Redux for state management (well except
that it is better then nothing).

For this type of things I've always used one or the other implementation of
State Machine pattern. Seems way more clear to me.

It is not just about JavaScript. State management is a part of many
applications and State Machine is a nice paradigm to work with. At least for
my taste.

~~~
acemarke
The key values of Redux are separating state update logic from the rest of the
app, emphasizing writing as much logic as possible as pure functions that are
easy to test, and enabling developers to better understand when, where, why,
and how their state is changing over time.

Note that it's entirely possible to write your reducer logic as state
machines, and in fact we explicitly encourage that :

[https://redux.js.org/style-guide/style-guide#treat-
reducers-...](https://redux.js.org/style-guide/style-guide#treat-reducers-as-
state-machines)

~~~
FpUser
In my opinion State Machine is sufficient on it's own. To me reducers seem
superfluous and in fact distracting from actually managing state. But as
already said it is my own opinion coming from my own experience. We do not
need to convince each other

------
larusso
I honestly have no clue about Redux. I know a bit about react and used Mobx
but I’m not a huge fan. When it comes to state managers and especially bigger
frameworks with best practice patterns I get reminded a lot about PureMVC.
This was the framework in the late 2000th that claimed to solve everything
because it’s so simple and slim. But with a bigger application the whole
boilerplate setup exploded. And don’t get me started with PureMVC pipes etc.
Reading the comments here sounds like Redux has kind of the same issues.

------
sandGorgon
What about the built-in Context api ?

~~~
zabana
Absolutely. For most projects it is more than enough. If you have a basic CRUD
app with token authentication you can get away with using that. There has been
better form support thanks to new libraries coming out recently so I don't see
reason to learn redux is, as was pointed out by other commenters, very verbose
and requires a lot of boilerplate code to get started.

The context API is baked in, no external lib required. If you can afford to
update your react codebase to the latest version without major breaking
changes I would totally migrate to the context API.

------
jtdev
Redux = functional zealotry

