How to create a frontend spa architecture with redux and components.

1. Dumb and smart
components & redux
Brecht Billiet

2. About me
Brecht Billiet
Frontend Architect - Coach - Trainer
http://brecht.io @brechtbilliet

3. Who still uses ng-
controller and ng-
include?

4. Doesn’t that bother you?
● What HTML belongs to what JS?
● Where do the templates live?
● Absolute template-paths are not maintainable
● What logic belongs in a controller or directive?
● This template should contain... oh wait, there is an ng-include there.
● How do you pass data to your controllers?

5. Think in components...
● 1 piece HTML + 1 piece LOGIC = COMPONENT
● You know it as: element directives
● Custom DOM tags
● A component has a single responsability
● We could use webcomponents + shadow DOM
● Sandboxed work
● Note: angular 1.5 has new component syntax

6. What should you
refactor to
components?

8. Everything is a component
● Your application is a tree of components
● Your pages are components
● Even your application is a component

9. application
Html + js
+ css
html + js
+ css
html + js
+ css
html + js
+ css
html + js
+ css
html + js
+ css
html + js
+ css
html + js
+ css
html + js
+ css
html + js
+ css
html + js
+ css

10. application
Html + js
+ css
fooPage
html + js
+ css
html + js
+ css
barPage
html + js
+ css
html + js
+ css
html + js
+ css
html + js
+ css
html + js
+ css
html + js
+ css
Routingconfig:
template: ‘<foo-page/>’
Routingconfig:
template: ‘<bar-page/>’

11. Easier to debug

12. Other advantages
● No scope soup
● Nice hierarchy view
● Single responsability
● No more absolute paths
● Easier to reason about
● Easier to refactor
● Easier to upgrade to ng2

13. What about attribute-directives?
● Let’s call them behaviors from now
● They add some logic to existing or custom components
● Separate them from your components folder

14. DEMO

15. http://winecellar.surge.sh

16. http://winecellar.surge.sh: components

17. Any rules of thumb?

19. Keep them small...

20. Keep them dumb where possible...

21. Dumb component Smart component (container)
Doesn’t know about the
application
Knows about the application
Doesn’t do data fetching Does data fetching
Main purpose is visualization Interacts the application
Reusable Not reusable
Only communicates with its direct
parent
Passes state and data to its
children
Doesn’t do state management Does state management

22. http://winecellar.surge.sh: Smart
components

23. http://winecellar.surge.sh: Dumb
components

24. State management
● State is very hard to manage in SPA’s
● State can be
○ data: results from REST calls
○ “sidebar is collapsed” or “spinner is active”
○ Which tab is currently active

25. State management
● 3 types of state
○ Data state
○ Application state
○ Inner state (e.g value of textbox) We don’t have to persist nor manage that

26. Why is it so hard to manage?
● 1-way databinding and 2-way databinding
● javascript references that are being broken and sometimes kept
● We can mutate the data in a million different ways
● No structure
● Data flows in different directions

27. application
state &
logic
state &
logic
state &
logic
state &
logic
state &
logic
state &
logic
state &
logic
state &
logic
state &
logic
state &
logic
Without flux

28. 1
2
5 6
3
7 8
4
9
10 11
Without flux

29. 1
2
5 6
3
7 8
4
9
10 11
I changed
Without flux

30. 1
2
5 6
3
7 8
4
9
10 11
I changed
So did I
Without flux

31. 1
2
5 6
3
7 8
4
9
10 11
I changed
So did I
My changes
should
reflect 6 and
4
Without flux

32. 1
2
5 6
3
7 8
4
9
10 11
I changed
So did I
My changes
should
reflect 6 and
4
I have to
subscribe
before 8
sends a
message
Without flux

33. 1
2
5 6
3
7 8
4
9
10 11
I changed
So did I
My changes
should
reflect 6 and
4
I have to
subscribe
before 8
sends a
message
I’m sending
an event
upwards
Without flux

34. 1
2
5 6
3
7 8
4
9
10 11
I changed
So did I
My changes
should
reflect 6 and
4
I have to
subscribe
before 8
sends a
message
I’m sending
an event
upwards
I’m sending
events
downwards
Without flux

35. 1
2
5 6
3
7 8
4
9
10 11
I changed
So did I
My changes
should
reflect 6 and
4
I have to
subscribe
before 8
sends a
message
I’m sending
an event
upwards
Without flux
I’m sending
events
downwards

36. 1
2
5 6
3
7 8
4
9
10 11
I changed
So did I
My changes
should
reflect 6 and
4
I have to
subscribe
before 8
sends a
message
I’m sending
an event
upwards
I get my data
from model x
and I can
update it
here
I get my data
from model z
Without flux
I’m sending
events
downwards
I get my data
from model y

37. 1
2
5 6
3
7 8
4
9
10 11
I changed
So did I
My changes
should
reflect 6 and
4
I have to
subscribe
before 8
sends a
message
I’m sending
an event
upwards
I get my data
from model x
and I can
update it
here
I get my data
from model z
Without flux
My data is
passed by
twoway
binding
I’m sending
events
downwards
I get my data
from model y
My data is
passed by
oneway
binding
My data is
passed by
twoway
binding

38. Where do those states/events come from?

39. Who updated my state??

40. Who updated/notified which component?

42. Flux helps with that
● Brings structure in data flow
● Not a framework but an architecture by facebook
● Unidirectional dataflow, oneway databinding
● Data flows from the top down
● Easier to reason about state

43. ● Action
○ Has an action type and a payload
● Dispatcher
○ Dispatches the actions to the store
● Store
○ Contains state
● View
Components

44. ● The unidirectional dataflow makes it easy to reason about

45. I use Redux!
Redux is based on
flux, but it’s easier

46. Redux
● Written by Dan Abramov (Facebook)
● Easier to use and less bloat
● Only has one store!!
● Completely Immutable data structure
● Uses reducers (pure functions)
● Flux approves

47. 1
2
5 6
3
7 8
4
9
10 11
STORE

48. 1
2
5 6
3
7 8
4
9
10 11
Me too
Me too
Me too
Me too
STORE
I only send
actions
upwards to the
store
I’m the single-
source-of-truth
in your
application!! ;-)

49. 1
2
5 6
3
7 8
4
9
10 11
Me too
Me too
I’m dumb I’m dumb
I’m dumb I’m dumb
I’m dumb
I’m dumb
STORE
Me too
I only send
actions
upwards to the
store Me too
I’m the single-
source-of-truth
in your
application!! ;-)
Dumb components only
notify their direct parents!
No state management
needed here :-)

50. What’s different?
● We have one single source of truth: the store
● We don’t update state ourselves anymore, the store handles all the state of
our application
● State is immutable
● Actions are always sent upwards

51. What’s different?
● Dumb components don’t do state management
● State is being updated by pure functions (reducers)
● When the store is updated it notifies all the smart components

52. Application state

53. Actions
● Actions have a type and a payload
● Keep the types together, gives clear overview

54. Actions

55. Reducers
● Pure functions
● reducer(state: MyState, action: Action): MyState
● they update the state
● Completely immutable

56. Reducers

57. Example in container

58. Middleware
● Easy logging, debugging
● Reproducible action state (pushable to server)
● Timetraveling with redux-devtools (requires react to be bundled in the
angular project)

59. Check it out
● egghead.io course (Free)
○ https://egghead.io/series/getting-started-with-redux

60. Special thanks to
● Kwinten Pisman (@kwintenp)
● Jurgen Van de Moere (@jvandemo)

61. Questions?

62. One more thing
Angular2, rxjs, redux,
@ngrx/store, Typescript,
webpack
http://workshop.brecht.io @brechtbilliet
Workshop
June 2016

63. Thank you!