Atomic Architecture
old and new ideas for structuring
front end applications
Slide 2
Slide 2 text
Dom Barker
• front end engineer
• mainly startups
Slide 3
Slide 3 text
The ‘ideal’ front end architecture
!
"
# index.html
$
Slide 4
Slide 4 text
The best Single Page Application
is the often the one that you
were wise enough to not build.
Slide 5
Slide 5 text
MAKE IT MORE LIKE AN APP
Slide 6
Slide 6 text
Single Page Applications
are really hard
Slide 7
Slide 7 text
• Javascript is not the friendliest language in the world
• Dynamic typing (ok that doesn’t have to be bad)
• General weirdness, e. g. == vs ===
• No nice features, not even string interpolation
• Awkward implementations of patterns, e.g. prototype
based inheritance
• protip: eschew inheritance altogether
• Capricious run time environment, e. g. error handling
• huge numbers of possible interactions
• all async!
• feedback into the DOM
• need to track all the data
• need to maintain performance
Slide 12
Slide 12 text
Model
View
Controller
Slide 13
Slide 13 text
No content
Slide 14
Slide 14 text
Model
View
Controller
Slide 15
Slide 15 text
• Maps to a thing (REST resource)
• Handles fetching and persistence
• Serious business logic (like validation)
Model / Collection
Slide 16
Slide 16 text
• Actually called a View in Backbone (nice one)
• Usually has an instance of a model
• listens for events on the DOM (submit form)
• listens for events on the model (change field)
• decides what to do about them
Controller
Slide 17
Slide 17 text
• Actually called a Template in Backbone (nice one)
• Renders html
• Often accepts a model
View
Slide 18
Slide 18 text
Not bad.
Slide 19
Slide 19 text
No content
Slide 20
Slide 20 text
λ
Functional Programming
Slide 21
Slide 21 text
No content
Slide 22
Slide 22 text
No content
Slide 23
Slide 23 text
OOP FP
verbs
actions!
nouns
things
Slide 24
Slide 24 text
Map
Slide 25
Slide 25 text
Reduce
Slide 26
Slide 26 text
Atomic Architecture
Redux
Slide 27
Slide 27 text
• One great big blob of data - the atom / store
• No models!
• No behaviour, just data - hash, array, whatever
• All in one place, no ambiguity
• State is immutable (read only)
• No classes, just pure functions
Slide 28
Slide 28 text
• create an action when something happens
• actions describe everything that occurs in the system
Slide 29
Slide 29 text
• Use a reducer to handle the action
• Reducers are pure functions
• They accept the old state, and the action as
parameters
• They return a new version of the state, without
modifying the original.
• new state gets sent to the store, and an event is
emitted
Slide 30
Slide 30 text
View
Action Creator Action Reducer
Store
Slide 31
Slide 31 text
• unidirectional dataflow
• predictable state
• action + data => new data
• pure functions are easy to test
• audit log of everything thats happened in the system
• time travel!
• restore state
• debug
• store on the server?
• live collaboration