Fluxy

Fluxy (adj): characteristics inherited / inspired by Facebook's Flux Architecture

Fluxy and Flux refer to the pattern

not specifically Facebook's Flux implementation

throughout this presentation...

What is the Flux Pattern?

What is Flux?

more of a pattern or architecture rather than a formal framework
vs. a MV* pattern
creating a shift in the front-end landscape (and beyond)
popularized by Facebook's Flux & React
not Facebook Flux & React specific; many possible implementations
- Flux, Reflux, Redux, Fluxxor, etc
- React, Riot, etc
- with superhuman discipline, you could implement it in about anything (even NG) ;-)

Why a New Pattern?

Why not traditional MV*?

https://facebook.github.io/flux/docs/overview.html

http://fluxxor.com/what-is-flux.html

abnormally simple MVC

model

view

controller

action

arrows represent an interaction between the different parts of the system
an action invokes some functionality in the controller
the controller potentially updates the model
the model changes are reflected in the view
user interaction in the view can change the model directly (2-way binding) or kickoff an action.

Adding a Couple of Views

https://facebook.github.io/flux/docs/overview.html

http://fluxxor.com/what-is-flux.html

abnormally simple MVC

model

view

controller

action

view

Adding Another Model

https://facebook.github.io/flux/docs/overview.html

http://fluxxor.com/what-is-flux.html

abnormally simple MVC

model

view

controller

action

view

model

Approaching Real World Conditions

https://facebook.github.io/flux/docs/overview.html

http://fluxxor.com/what-is-flux.html

still a pretty simple MV*

model

view

model

view

model

view

model

view

model

view

model

view

model

view

controller

No 2-Way Binding?

https://facebook.github.io/flux/docs/overview.html

http://fluxxor.com/what-is-flux.html

still a pretty simple MV*

model

view

model

view

model

view

model

view

model

view

model

view

model

view

controller

still problematic at scale

prone to bugs

that are hard to debug

hard for humans to reason with

Scope Creep

model

view

model

view

model

view

model

view

model

view

model

view

model

view

to fully understand this

<---------

{

you must understand all this

and know all the places where state can be mutated

}

and maybe this

and potentially how

controller

and maybe this

Banana vs Jungle

maybe these

difficult

to undertand
when inheriting such a project
to onboard new devs
to maintain
to add new features
to test
etc

How is Flux Different?

1. Unidirectional Data Flow

"Data Flows Down"

~~view~~

~~model~~

{}

</>

subscribes to store
reacts to store's state
stateless*
can't change itself directly*
- no imperative manipulations
a pure function of state
- no scope creep

contains the model
the model can't be changed directly
allows subscribers
notifies listeners when changes to state occur

store

~~view~~

store

{}

</>

smart component

</>

dumb components

subscribes to store
reacts to store's state
stateless*
can't change itself directly*
a pure function of state
composes dumb components
aka: Controller-Views

contains the entire apps' state / view-model
immutable or not directly mutable
notifies listeners when changes to state occur

100% decoupled*
- from store, smart component, each other
pure / reactive
reusable
composable
all dependencies injected via props*

view

all completely reactive to store

export default ({ people }) => {

    let list = people.map( person => (
        <li>
            <strong>{ person.name }</strong>
            : <small>{ person.about }</small>
        </li>
    ));
	
    return people.length
        ? <ul>{ list }</ul>
        : <strong>No Peeps</strong>;

};

Dumb Component (JSX)

No Dependencies

https://jsbin.com/qeguge/edit?js,output

{}

</>

Pop Quiz

How do I change the rendered UI of this component?

Change the state in the store.

Okay, so how do you change the state in the store?

How is Flux Different?

2. Store vs Model

Store

contains the model / state
- is a plain old JS object (POJO)
- single source of truth
  - only place in app where state is kept
contains the logic to change its state
- predefined list of all mutations called Action Handlers (or reducers)
- mutations are always synchronous
listens for and reacts to dispatched Actions
- no traditional getters / setters
- change requests are broadcasted in
- can't mutate state in any other way
emits notifications to subscribers when changes occur

-------
-------
-------

{}

Store

model / state

notifier

action handler(s)

listener

regarding the store: as an app dev, you only write action handlers

-------
-------
-------

{}

Actions

plain old JavaScript object (POJO)
type key names the mutation
- only required key
- unique across app (or collisions)
the rest of the structure is up to you
- minimalism recommended

{
    "type": "ADD_PERSON",
    "name": "Jared",
    "location": "South Jordan, UT",
    "food": ["pizza", "bacon"]
}

example action

action handler

to understand action handlers, let's talk...

Actions & Handlers

{
    "type": "INCREMENT_COUNTER"
}

function myCounter(state=0, action) {
    switch(action.type) {
        case "INCREMENT_COUNTER":
            return state+1;
        case "DECREMENT_COUNTER":
            return state-1;
        default:
            return state;
    }
}

usually a switch statement
checks for a matching`action.type`
optionally performs the mutation

action handler

action

asks store to make a mutation, hangs up
blissfully ignorant
- current state
- how mutations occurs
- if mutation occurs

Example Store (Redux)

import { createStore } from 'redux'


function todos(state = [], action) {
    switch (action.type) {
        case 'ADD_TODO':
            return state.concat({
                task: action.item,
                id: state.length+1
            }); 

        case 'REMOVE_TODO':
            return state.filter(item=>item.id!==action.id);

        default:
            return state
    }
}

let store = createStore(todos);

store.subscribe( () => console.log(
    store.getState()
));

https://jsbin.com/quyotan/edit?js,console

How is Flux Different?

3. Actions Float Up

-------
-------
-------

{}

store

action creators

</>

view

action

handlers

state

notify

smart component

dumb components

What's Missing?

dispatched action

listener

action creator

Action Creators

a function which returns an action object
abstracts away the details of the action object structure
where you'd find async code that talks to servers
it's the upstream glue between the store and smart-components

dispatched action

Action Creators

export function addTodo(text) {
    return {
        type: ADD_TODO,
        text
    };
}

http://rackt.org/redux/docs/basics/Actions.html

import { dispatch } from './store.js';
import { addTodo } from './actions/add-todo.js';
import { Dumb } from './components/dumb.js';

// to be passed into dumb component(s)
let add = text => (
    dispatch( addTodo(text) )
);

// later usage:
<Dumb addAction={add} />

../actions/add-todo.js

./some/smart-component.js

How is Flux Different?

4. Distinct, Composable Parts

Quick Poll

-------
-------
-------

{}

</>

action

handlers

smart component

dumb components

action

listener

action creator

state

notifier

who believes they:

decently understand this whole system?
are ready to write a fluxy app now (if provided a project-starter)?
understand parts, but are still making the connections?
are completely lost?

you know what's awesome?

you don't need to understand the whole jungle to start writing bananas!

-------
-------
-------

{}

</>

action

handlers

smart component

dumb components

action

listener

action creator

state

notifier

Of this system, these are the things you write

action creator(s)
action handler(s)
smart components
dumb components

-------
-------
-------

{}

</>

action

handlers

smart component

dumb components

action

listener

action creator

state

notifier

Action Handlers & Dumb Components

are blissfully ignorant of any other part of the jungle
provided a few rules, any developer* could start writing these today
are pure functions & have no library dependencies
it may be preferable to write these without knowledge of any other part of the app
are application agnostic / extremely reusable

-------
-------
-------

{}

</>

action

handlers

smart component

dumb components

action

listener

action creator

state

notifier

Action Creator

no coupling, high cohesion
- only need to know emitted action's structure
more app specific, but decoupled enough for potential reusability
also export their functionality

thus, requires some awareness of the system

-------
-------
-------

{}

</>

action

handlers

smart component

dumb components

action

listener

action creator

state

notifier

Smart Component / Controller-View

it imports the store to which it subscribes
it imports and composes dumb components
it imports and composes actions
subscribes to the store
disperses data and actions to dumb components
is app specific
essentially is just a smart composition

Distinct Units

reusable
repeatable
extensible
composable
SRP
pure function
encapsulated
swappable

each unit is:

TESTABLE!

How is Flux Different?

5. Scales Gracefully

FTW

Fluxy Scalability

-------
-------
-------

{}

</>

action

handlers

smart component

dumb components

action

listener

action creator

state

notifier

start with

2 action creators
1 action handler / reducer
1 smart component
3 dumb components

-------
-------
-------

{}

</>

action

handlers

smart component

action

listener

action creator

state

notifier

</>

Add Dumb Components

no effect on system complexity

-------
-------
-------

{}

</>

action

handlers

smart component

action

listener

action creator

state

notifier

</>

Add Smart Components

</>

no effect on system complexity

-------
-------
-------

{}

</>

action

handlers

smart component

action

listener

action creator

state

notifier

</>

Add Action Handlers

may result in more action creators

-------
-------
-------

-------
-------
-------

-------
-------
-------

but no increase in system complexity

</>

so, as your app grows bigger...

complexity

does not!!

Other Visual Representations

per Google Image search ;)

action

view

store

dispatch

action creator

smart component

store

dispatch

dumb component

api

user

interaction