Flux Architecture

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.