Flux Architecture电子书

Flux Architecture

Flux Architecture

Credits

About the Author

About the Reviewer

www.PacktPub.com

eBooks, discount offers, and more

Why subscribe?

Preface

What this book covers

What you need for this book

Who this book is for

Conventions

Reader feedback

Customer support

Downloading the example code

Errata

Piracy

Questions

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

2. Principles of Flux

Challenges with MV*

Separation of concerns

Cascading 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

3. Building a Skeleton Architecture

General organization

Directory structure

Dependency management

Information design

Users don't understand models

Stores 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

4. Creating Actions

Action names and constants

Action name conventions

Static action data

Organizing action constants

Feature action creators

When modularity is needed

Modular 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

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 creators

Composing action creators

Returning promises

Synchronizing without promises

Composing asynchronous behavior

Handling errors

Summary

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

Dealing with store complexity

Too many stores

Rethinking feature domains

Summary

7. Viewing Information

Passing views data

Data via the change event

Views decide when to render

Keeping views stateless

UI state belongs in stores

No querying the DOM

View responsibilities

Rendering store data

Subview structure

User interactivity

Using ReactJS with Flux

Setting the view state

Composing views

Reacting to events

Routing and actions

Summary

8. Information Lifecycle

Component life cycle difficulties

Reclaiming unused resources

Hidden dependencies

Memory leaks

Flux structures are static

Singleton pattern

Comparison to models

Static views

Scaling information

What scales well?

Minimal information required

Actions that scale

Inactive stores

Deleting store data

Optimizing inactive stores

Keeping store data

Summary

9. Immutable Stores

Renouncing hidden updates

How to break Flux

Getting store data

Everything is immutable

Enforcing unidirectional data flow

Backwards, sideways, and leaky data flow

Too many stores?

Not enough actions

Enforcing immutability

The cost of immutable data

Garbage collection is expensive

Batched mutations

Offsetting the cost

Using Immutable.js

Immutable lists and maps

Immutable transformations

Change detection

Summary

10. Implementing a Dispatcher

Abstract dispatcher interface

Store registration

Dispatching payloads

Handling dependencies

Challenges with the dispatcher

Educational purposes

Singleton dispatchers

Manual store registration

Error-prone dependency management

Building a dispatcher module

Encapsulating store references

Handling dependencies

Dispatching actions

Improving store registration

Base store class

An action method

Summary

11. Alternative View Components

ReactJS is a good fit for Flux

ReactJS is unidirectional

Re-rendering new data is easy

Small code footprint

The downsides of ReactJS

Virtual DOM and memory

JSX and markup

Vendor lock-in

Using jQuery and Handlebars

Why jQuery and Handlebars?

Rendering templates

Composing views

Handling events

Using VanillaJS

Keeping my options open

Moving to React

New hotness

Summary

12. Leveraging Flux Libraries

Implementing core Flux components

Customizing the dispatcher

Implementing a base store

Creating actions

Implementation pain points

Dispatching asynchronous actions

Partitioning stores

Using Alt

The core ideas

Creating stores

Declaring action creators

Listening for state changes

Rendering views and dispatching actions

Using Redux

The core ideas

Reducers and stores

Redux actions

Rendering components and dispatching actions

Summary

13. Testing and Performance

Hello Jest

Testing action creators

Synchronous functions

Asynchronous functions

Testing stores

Testing store listeners

Testing initial conditions

Performance goals

User perceived performance

Measured performance

Performance requirements

Profiling tools

Asynchronous actions

Store memory

CPU utilization

Benchmarking tools

Benchmarking code

State transformations

Summary

14. Flux and the Software Development Lifecycle

Flux is open to interpretation

Implementation option 1 – just the patterns

Implementation option 2 – use a Flux library

Roll your own Flux

Development methodologies

Upfront Flux activities

Maturing a Flux application

Borrowing ideas from Flux

Unidirectional data flow

Information design is king

Packaging Flux components

The case for monolithic Flux

Packages enable scale

Installable Flux components

Summary

Index