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.
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)
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.