Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Cost of immutability #328
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
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.)
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...
referenced this issue
Sep 21, 2015
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))
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