4 ms·

I think immutability is actually the crux of the problem here. Why is it used? So the UI knows when to update... Redux applies layers of complexity just to know

by weq 9y ago

I think immutability is actually the crux of the problem here. Why is it used? So the UI knows when to update... Redux applies layers of complexity just to know when ur UI is going to update (efficiently)... Thats a scaling issue! So ur store cant scale to large data-sets because of immtability, and your app cant properly model ur domain, because it needs to be flat to support updates. That shouldnt be an afterthought for a state management library that uses the principles of event sourcing to create a state tree. I think its these two ideas clashing that causes the verbose code, the community complaints, and slow code as described in the post. Why should i need to mutate references? IMO it would be alot more palatable if redux persisted events, not the store. And was opined about the event structure, instead of everything else. ie. Use inheritance/events to then control UI updates. ie. NOT Comment_Added { postId:.., comment: .. } rather Comment_Added : PostDomainEvent {comment: ..} now on the page where i am viewing a current_post, i can simply connect to my state, and re-render whenever i see a PostDomainEvent of id == current_post_Id. I can also buffer re-renders based on the amount of postDomainEvents i see per second. This way, as someone using the library, my events are my focus, not my store. I dont need to remember to mutate this, or do that. I get precise control, and anyone can implement the store in any technology they want. sure i need an "unreduce" to get time-travel debugging, but thats not a trade-off thats forced on ppl who dont need it.

acemarke 9y ago
For what it's worth, immutability matters for more than _just_ having React-Redux properly update. It also matters for time-travel debugging, and to some extent for proper reducer testing. I'd very much disagree with the phrases "can't scale to large data-sets because of immutability", and "app can't properly model your domain". If you follow the suggested pattern of normalizing your state like a database [0], then modeling relationships between data types is entirely feasible, AND you can update the individual items efficiently (and if you don't want to write that code manually, there's a ton of addon libraries to help you manage those relationships [1] [2] [3]). At that point, the only real limit to how much data you load is browser memory, same as any other client-side framework. [0] http://redux.js.org/docs/recipes/reducers/NormalizingStateShape.html http://redux.js.org/docs/recipes/reducers/NormalizingStateSh... [1] https://github.com/tommikaikkonen/redux-orm https://github.com/tommikaikkonen/redux-orm [2] http://blog.isquaredsoftware.com/2016/10/practical-redux-part-1-redux-orm-basics/ http://blog.isquaredsoftware.com/2016/10/practical-redux-par... [3] https://github.com/markerikson/redux-ecosystem-links/blob/master/entity-collection-management.md https://github.com/markerikson/redux-ecosystem-links/blob/ma...
- weq 9y ago
  Exactly, lets say my data structure stretches the clients memory, adding immutability ontop of it doesnt cut the mustard because its not baked into the language. Thats my point, "redux" doesnt scale. "Time-travel debugging" doesnt scale either (as implemented by popular middleware), because serialising my state on every transition is 5MB + 5.0001MB + 5.00012MB etc etc operation. Immutability is great for parallel applications, in browser JS is not one such app. Not yet anyway. Additionally, i question the logic of "normalising" my data structure for the client --> just so i can update my UI efficiently. Whats the point of using universal JS? What i am saying is redux NEEDS immutability to deliver on its promise "out of the box" - lets face is, sure u can extend redux to mute this requirement, but then whats the point of all that boilerplate? So u can use devtools? So u can use off-the-shelf middleware to speed up ur dev? RAPID app development? Cause in a few years those tools wont be supported, and u will be stuck with a legacy boilerplate mess. i argue that a FULLY event-sourced model would negative all this and make everything scale without any tricks. The diciple of event-sourcing will negate the need of immutability in every case. Additionally the cognitive load of "events, reducers and reference equality" is very different from "events, reducers and events". Go all with event sourced domain models and get all the benifits. Represent the way your domain does. Represent ur state changes to your domain with events. Make an event heirarchy so u can preciesesly update ur UI around its state transitions. If redux persisted events INSTEAD of the composed state, none of these problems would exist AND you would get time-travel. Then u can snap-shot ur state periodically to reduce load times. Instead redux uses events to trigger state changes, and snapshot diff'ing to trigger ui changes.
  - joncampbelldev 9y ago
    redux is the best you can get in JavaScript for functional UI coding ... but clojurescript+reframe utterly destroys js+redux on every feature (in the context of making functional web apps)

by weq 9y ago

acemarke 9y ago

For what it's worth, immutability matters for more than _just_ having React-Redux properly update. It also matters for time-travel debugging, and to some extent for proper reducer testing. I'd very much disagree with the phrases "can't scale to large data-sets because of immutability", and "app can't properly model your domain". If you follow the suggested pattern of normalizing your state like a database [0], then modeling relationships between data types is entirely feasible, AND you can update the individual items efficiently (and if you don't want to write that code manually, there's a ton of addon libraries to help you manage those relationships [1] [2] [3]). At that point, the only real limit to how much data you load is browser memory, same as any other client-side framework. [0] http://redux.js.org/docs/recipes/reducers/NormalizingStateShape.html http://redux.js.org/docs/recipes/reducers/NormalizingStateSh... [1] https://github.com/tommikaikkonen/redux-orm https://github.com/tommikaikkonen/redux-orm [2] http://blog.isquaredsoftware.com/2016/10/practical-redux-part-1-redux-orm-basics/ http://blog.isquaredsoftware.com/2016/10/practical-redux-par... [3] https://github.com/markerikson/redux-ecosystem-links/blob/master/entity-collection-management.md https://github.com/markerikson/redux-ecosystem-links/blob/ma...

weq 9y ago
Exactly, lets say my data structure stretches the clients memory, adding immutability ontop of it doesnt cut the mustard because its not baked into the language. Thats my point, "redux" doesnt scale. "Time-travel debugging" doesnt scale either (as implemented by popular middleware), because serialising my state on every transition is 5MB + 5.0001MB + 5.00012MB etc etc operation. Immutability is great for parallel applications, in browser JS is not one such app. Not yet anyway. Additionally, i question the logic of "normalising" my data structure for the client --> just so i can update my UI efficiently. Whats the point of using universal JS? What i am saying is redux NEEDS immutability to deliver on its promise "out of the box" - lets face is, sure u can extend redux to mute this requirement, but then whats the point of all that boilerplate? So u can use devtools? So u can use off-the-shelf middleware to speed up ur dev? RAPID app development? Cause in a few years those tools wont be supported, and u will be stuck with a legacy boilerplate mess. i argue that a FULLY event-sourced model would negative all this and make everything scale without any tricks. The diciple of event-sourcing will negate the need of immutability in every case. Additionally the cognitive load of "events, reducers and reference equality" is very different from "events, reducers and events". Go all with event sourced domain models and get all the benifits. Represent the way your domain does. Represent ur state changes to your domain with events. Make an event heirarchy so u can preciesesly update ur UI around its state transitions. If redux persisted events INSTEAD of the composed state, none of these problems would exist AND you would get time-travel. Then u can snap-shot ur state periodically to reduce load times. Instead redux uses events to trigger state changes, and snapshot diff'ing to trigger ui changes.
- joncampbelldev 9y ago
  redux is the best you can get in JavaScript for functional UI coding ... but clojurescript+reframe utterly destroys js+redux on every feature (in the context of making functional web apps)