Atomic Architecture

Transcript

1. Atomic Architecture old and new ideas for structuring front end applications
2. Dom Barker • front end engineer • mainly startups
3. The ‘ideal’ front end architecture ! " # index.html $
4. The best Single Page Application is the often the one that you were wise enough to not build.
5. MAKE IT MORE LIKE AN APP
6. Single Page Applications are really hard
7. • 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
8. • Browser compatibility. Still. • Immature tooling • grunt / gulp / broccoli / jake / ?? • Distributed • connectivity • failures • timeouts
9. Interaction & State
10. click blur mouseleave resize keyup animationiteration DOMContentLoaded SVGAbort scroll touchmove submit wheel
11. • huge numbers of possible interactions • all async! • feedback into the DOM • need to track all the data • need to maintain performance
12. Model View Controller
14. Model View Controller
15. • Maps to a thing (REST resource) • Handles fetching and persistence • Serious business logic (like validation) Model / Collection
16. • 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
17. • Actually called a Template in Backbone (nice one) • Renders html • Often accepts a model View
18. Not bad.
20. λ Functional Programming
23. OOP FP verbs actions! nouns things
24. Map
25. Reduce
26. Atomic Architecture Redux
27. • 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
28. • create an action when something happens • actions describe everything that occurs in the system
29. • 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
30. View Action Creator Action Reducer Store
31. • 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
32. f(data) => View
33. ! " # index.html $ f(d) =>