Flux Architecture

Description

Cover; Copyright; Credits; About the Author; About the Reviewer; www.PacktPub.com; Table of Contents; Preface; Chapter 1: What is Flux?; Flux is a set of patterns; Data entry points; Managing state; Keeping updates synchronous; Information architecture; Flux isn't another framework; Flux solves conceptual problems; Data flow direction; Predictable root cause; Consistent notifications; Simple architectural layers; Loosely coupled rendering; Flux components; Action; Dispatcher; Store; View; Installing the Flux package; Summary; Chapter 2: Principles of Flux; Challenges with MV*;Annotation Cover Copyright Credits About the Author About the Reviewer www.PacktPub.com Table of Contents Preface Chapter 1: What is Flux? Flux is a set of patterns Data entry points Managing state Keeping updates synchronous Information architecture Flux isn't another framework Flux solves conceptual problems Data flow direction Predictable root cause Consistent notifications Simple architectural layers Loosely coupled rendering Flux components Action Dispatcher Store View Installing the Flux package Summary Chapter 2: Principles of Flux Challenges with MV* Separation of concernsCascading updates Model update responsibilities Unidirectional data From start to finish No side-effects Explicit over implicit Updates via hidden side-effects Data changes state in one place Too many actions? Layers over hierarchies Multiple component hierarchies Hierarchy depth and side-effects Data-flow and layers Application data and UI state Two of the same thing Tightly coupled transformations Feature centric Summary Chapter 3: Building a Skeleton Architecture General organization Directory structure Dependency management Information design. Users don't understand modelsStores map to what the user sees What do we have to work with? Putting stores into action Fetching API data Changing API resource state Local actions Stores and feature domains Identifying top-level features Irrelevant API data Structuring store data Bare bone views Finding missing data Identifying actions End-to-end scenarios Action checklist Store checklist View checklist Summary Chapter 4: Creating Actions Action names and constants Action name conventions Static action data Organizing action constants Feature action creators. When modularity is neededModular architecture Mocking data Mocking existing APIs Mocking new APIs Replacing action creators Stateful action creators Integrating with other systems Web socket connectivity Parameterized action creators Removing redundant actions Keeping actions generic Creating action partials Summary Chapter 5: Asynchronous Actions Keeping Flux synchronous Why synchronicity? Encapsulating asynchronous behavior Asynchronous action semantics Making API calls APIs are the common case API calls and user interactivity Combining API calls. Complex action creatorsComposing action creators Returning promises Synchronizing without promises Composing asynchronous behavior Handling errors Summary Chapter 6: Changing Flux Store State Adapting to changing information Changing API data Changing feature functionality Impacted components Reducing duplicate store data Generic store data Registering generic stores Combining generic and specific data Handling store dependencies Waiting for stores Data dependencies UI dependencies View update order Store registration order Prioritizing view rendering.