Immutability is for UI, You, and I
summary
Argues that treating component state as a stream of discrete frames — an immutable model for UI — removes timing bugs and makes debugging, logging, undo/redo and refactoring far simpler. Demonstrates moving from Ember.Object observers to replace whole model on every change, using plain old JavaScript objects and getters, and integrating ideas from omniscient/ohm and Glimmer. Shows a general-purpose form library, pagination and reactive XHR helpers implemented this way and reports that they work and simplify reasoning about state.
AI-written summary · about
chapters (19)
- 0:00My history with backbone
- 1:44Problems with complexity
- 3:02Switching to ember
- 4:28Facing ember limitations
- 5:52Discovering immutability
- 7:45The form library challenge
- 10:42Debugging complex state
- 12:24Seeking new approaches
- 13:21The MVC architecture
- 14:28Adopting the movie pattern
- 15:55Immutable frame architecture
- 17:21Applying movie to ember
- 18:22Two steps to immutability
- 20:27Simplifying the runtime
- 21:51Using javascript getters
- 23:24Tracking state changes
- 24:48Preserving information
- 25:45Implementing undo-redo
- 26:48Conclusion and gratitude
related talks
26mBuilding Better Components
33mThe Observer tip-jar
26mAmbitious UX for Ambitious Apps
27mOn the Development of Reactive Systems with Ember.js
24mNew to Ember: What ARE All These Things?
28mAwesome Ember Tricks
26mInteraction Design with Ember 2.0 and Polymer
40mEmber's Technical Foundations – And How They Are Changing