http://m.youtube.com/watch?v=xsSnOQynTHs
Related to blog-post-rethinking-flux
Spends too much time battling the small mistakes that he makes while doing iterative development.
talk-hot-reloading-with-time-travel#redo-steps-while-iterating1 At 3:15 "If you're iterating on your data transformations and you have some actions that cause those transformations, like you click a button and something happens, you need to redo these steps every time you change a function, because you have to make sure they work correctly." talk-hot-reloading-with-time-travel#redo-steps-while-iterating1
if you have changes to the model that are because of button hits for whatever he have to redo those changes every time you do iterate on the model.
At 8:38 web pack has a feature called hot model replacement.
At 9:30 only possible because render() in React does not have side effects.
At 9:50 uses Style Loader to do something similar for the CSS.
At 11:10 - Store in Flux does too many things to be amenable to the React hot loader way of working.
At 11:33 The boilerplate is in concepts, not in syntax.
At 12:00 the store should not register itself. It should be registered/deregister by the thing that uses it.
At 12:30 changes a mutation to an assignment because it's hard to write powerful developer tools if you are mutating state all over the place.
At 13:15 - getters are moved to a separate place
talk-hot-reloading-with-time-travel#immutable-objects-facilitate-fast-reference-comparison1 At 14:00 - Whatever calls the "handle" function can call the canonical getState before and after the function and if the reference has changed (because it's immutable), then the state has changed. No need for emitting a state change event. (Gordon note: this could allow for objects to reconcile on their own, with control-loops where they decide on their desired change based on the fact that there is a change, and what the change between the previous and current versions of the data are.) talk-hot-reloading-with-time-travel#immutable-objects-facilitate-fast-reference-comparison1
At 1540 deflect stores core concept is how state is changed by an action. He passes in the state and an action alters the state and returns it
At 1610 it is a reducer, not a store.
talk-hot-reloading-with-time-travel#root-reducer1 At 17:40 unlike event emitters, pure functions are very easy to compose. This is the purpose of a root reducer. talk-hot-reloading-with-time-travel#root-reducer1
At 1830 he has a debugging told that shows all of the state and actions that happen in his app. It shows action, state. How the actions change the state.
At 26 he talks about exporting a unit test from the debugging session.