New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cost of immutability #328

scisci opened this Issue Jul 26, 2015 · 5 comments


4 participants

scisci commented Jul 26, 2015

im excited about this project but worried that this technique of creating a new state object on every change to the store would tax the gc and performance in a large application. Would be good to see some tests or explanations about why I shouldn't be worried about this


This comment has been minimized.


gaearon commented Jul 26, 2015

Well, Om apps work exactly like this and don't seem to have these kinds of problems. When you want to squeeze additional bits of performance, you can use Immutable or Mori which, unless I am mistaken, better utilize memory by implementing persistent data structures using structural sharing.

Finally, nothing per se prevents you from mutating your Redux state tree. It is actively discouraged, and you will lose a lot of debugging benefits if you mutate your data, but for performance critical pieces you can write impure reducers that mutate the state in place. (Only do that if you're sure that's where the lag comes from—not likely to be an issue in real apps.)

@gaearon gaearon added the question label Jul 27, 2015


This comment has been minimized.


gaearon commented Jul 27, 2015

Don't forget that even with traditional Flux you're still likely to allocate objects in your store getters or in your components' setState method calls. It's not like one or two objects allocated with Redux will change much.

@gaearon gaearon closed this Jul 27, 2015


This comment has been minimized.

scisci commented Jul 27, 2015

Thanks for your response. It could very well be a more generic react/flux question (I'm new to both). Thanks for addressing it anyway. I'm only planning on building a traditional web app for now, but who knows, might want to create a web version of After Effects one day...


This comment has been minimized.

inkless commented Aug 21, 2015

This is exactly the same concern as mine. Thanks for the explanation.


This comment has been minimized.

deathmood commented Mar 10, 2016

@gaearon just looked into - 3 principles and there:

State is read-only
The only way to mutate the state is to emit an action, an object describing what happened.

like some kind of misconception --- because as far as I understand mutating state is very discouraged

PS: morover than follows the third principle that contradicts the second haha))

Changes are made with pure functions
To specify how the state tree is transformed by actions, you write pure reducers.

So second principle says that you can mutate state. And third says that actually to make mutation you can use pure functions))) haha

PPS: maybe it is better to replace all mutation words in second principle with change words?
Cause change does not mean mutation. Should I open PR for this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment