React. Flux. Redux. by Andrey Kolodnitskiy

Editor's Notes

• #10: Working with DOM – Virtual DOM Reusability – Everything is a component that contains logic & UI for Complexity – Application is divided into set of small independent, reusable and stateless components and follows data flow architecture
• #12: Instead of changing real DOM we are changing its lightweight in-memory representation Then diff between previous in-memory copy and new is defined Then diff is applied to the real DOM React Virtual DOM implementation knows When and How to effectively apply changes By applying changes only when needed and minimizing number of operation with real DOM we get better performance
• #13: In React everything is a component Component is self-contained and can be placed anywhere if we suit its interface Component has lifecycle events it can react to Component contains layout (UI) Component has defined interface Can contain other components Should be stateless Note: Component is meant in general sense. Let’s skip React.Element vs React.Component for simplicity reasons
• #15: UI & logic is in one file. My component is responsible for everything, what a hell! What about SRP and Separation of concerns, have you heard of?
• #16: Let’s think of it differently. The component handles everything and thus can be easily reused Normally when you adjust component logic you have to update its template So for the 1 reason of change you do change 2 files It is easier to figure out component logic and its representation when everything tied together
• #17: Application has to be split into series of small components which are responsible for small piece of logic and thus they are quite simple There is data flow concept which defines how component should get/set data which makes easy to track all the changes
• #18: So what that brings: Same data produces same view output Data changes are predictable and easier to track related changes
• #19: So what that brings: Same data produces same view output Data changes are predictable and easier to track related changes
• #20: So what that brings: Same data produces same view output Data changes are predictable and easier to track related changes
• #21: So what that brings: Same data produces same view output Data changes are predictable and easier to track related changes
• #24: Dispatcher: The dispatcher is the central hub that manages all data flow It is a registry of callbacks into the stores In other words: mechanism to deliver actions into the stores Action: Typically triggered by the View Contains information about change made to the application Store: Contain application state and logic Reacts to specific actions Issue events when data or state is updated View: Has list of stores which provide data for Triggers actions with the state change Reacts to specific events in the store
• #25: So what that brings: Same data produces same view output Data changes are predictable and easier to track related changes
• #29: The issue here is that we cannot create new actions while handling an action. As a result our code has to get back to the view which will dispatch new actions. The View now has information about application logic how/when to start new actions. Has a lot of boilerplate code which waits for the action execution to start new actions. Our views become messy
• #34: Store: Holds application state Allows state to be updated via dispatch Register/Unregister state change listeners Actions and Action creators Actions describe that fact that something happened Action creators are functions that create actions Actions and action creators can be async Can dispatch other actions Reducers Pure functions Should be stateless reducer(currentState, action) { return newState; } In case state is not changed return passed state back Do not modify passed state (State has to be Immutable)