
Ask HN: Reasons not to use Redux? - horsecaptin
Hey everyone,
I understand Redux and why to use it to store application state. I was wondering, are there reasons to not use Redux?<p>For example, since Redux is a monolothic store of application state, could the state tree get too big?
======
hoodoof
I like redux but I did not need it. I wish I had seen this before learning
redux:

[http://andrewhfarmer.com/component-
communication/](http://andrewhfarmer.com/component-communication/)

~~~
JFB_adams
Great read

------
JohnMunsch
I just used Redux on something pretty complex. The page starts with four
different API calls to get a mass of data with which it populates the state
and the page can get going. It does anywhere from 1 to 25 more calls to get
graph data but that comes down while the page is already in a state where the
user can start interacting with it.

Any time the user interacts with the data on one line (among hundreds or
thousands) calculations are redone at four different levels so we don't have
to keep going back to the back-end to update the data, instead we can keep
working with the data we already have.

So... With all that said, how did it work with Redux. Eh. Not so bad. I don't
love it the way I loved AngularJS after I used it for the first time, but it's
OK. The results are complicated but given how we're using it and what we're
doing, I don't know how it wouldn't be complicated. I dislike that there's
going to be a significant learning curve for anyone who encounters this page
in the future, but the previous version of the page was a total trainwreck. At
least this time I can do a lot of stuff and envision changes to the
calculations and how it all updates and I don't break out in a sweat.

The biggest area I ran into problems was that a lot of the data we need to
keep up-to-date is derived data (for example, an array of data for Angular UI
Grid which has to use a heavily modified version of data in the state). Redux
doesn't really do anything to help you update that as needed.

There are a lot of reasons there are so many plugins and add-ons for Redux, I
think you might find it interesting to go over those so you can learn some of
the themes they have and see what problems they try to solve. Actually, I
think that's a worthwhile thing to do with any new technology. Go look at all
the software which has sprung up to fill in the holes and you'll learn a lot.

------
matthewtoast
I would at least be careful using Redux to push realtime animation state
changes. Returning a fresh application state every 16.6 milliseconds means a
lot of object allocations, which means garbage collection, which means UI
freezes turning your smooth animation design into an unpleasant experience.

There may be a general solution for this out there, or at least an approach
that makes it workable for some cases, but I haven't come across it yet. And
of course it really depends on how demanding your performance needs are. You
might be able to get away with using Redux for animations despite the above.

It would be great to see something like Redux that gives you debugging
precision all the way down to the animation frame, but which avoids the
garbage problem.

~~~
iamwil
That shouldn't be a problem if you're using an immutable store for your
application state. As I understand it, immutable stores are logically a
completely different object, but under the hood, it reuses the elements so
you're not creating objects all the time.

------
zachrose
Maybe your application isn't that complex, and it's more succinctly modeled as
as an object or two with mutable state. (E.g. a media player.)

Maybe your application is simpler to model as a mutable assembly of little
pieces, where the protocols between those pieces are more important than
managing their arrangement. (Maybe like in a modular synth?)

Maybe an existing team or project already has a good thing going without using
Flux.

However, all of these are pretty thin and narrow. Getting rigorous control of
the state of your program is actually super useful, as is treating events like
immutable facts that build upon each other.

------
eskim0
Because redux makes it easier to share and compute state I would argue that it
makes it easier to think more clearly about state design. This clarity allows
the developer to make more conscious decisions to what state is stored.

In contrast an MVC application encourages modulization of discrete components
of an app. Which could lead to situations in which state could be duplicated.
To get around this, singletons can be used to avoid duplication. This involves
a central store. Much like a single state tree.

