Introduction to Flux Architecture Pattern

Wenn man mit React größere Single Page Applikationen bauen will, kommt man mit "reinem React" möglicherweise an die Grenzen, wenn viele Komponenten auf dem selben Business Model arbeiten: wer ist für das Verändern des Models verantwortlich? Welche Komponenten müssen bei Änderungen am Model benachrichtigt werden? Das sind nur einige Fragestellungen in diesem Zusammenhang. Antworten verspricht hier das Flux Architektur Model, das Facebook für die Entwicklung großer React Anwendungen entworfen hat. Auf dem Treffen der Hamburger React Meetup Gruppe am 19.08. stelle ich die Grundlagen von Flux vor.

Transcript

1. REACT  MEETUP  HAMBURG   FLUX  INTRODUCTION   Nils  Hartmann  (nils@nilshartmann)  
2. REACT  MEETUP  HAMBURG   WHY  FLUX?   Some  background  first...  
3. CommunicaNon   •  Down  via  proper,es   •  Up  via  callbacks     Top-­‐level  component   •  Works  on  single  model   •  (whatever  a  ‚model‘  is)   SINGLE  COMPONENT  HIERARCHIE   Component 3 Component 2 Component 1 props props callback Model (whatever that means)
4. Isolated  Models  with  independent  component  trees   •  Each  component  (tree)  works  on  its  own  model   •  Peaceful  co-­‐exsitence     MULTIPLE  COMPONENT  HIERARCHIES  (I)   Component 3 Component 2 Component 1 props props callback Model 1 (whatever that means) Component C Component B Component A props props callback Model 2 (whatever that means)
5. Shared  Model  with  independent  component  trees   •  Each  component  (tree)  works  on  the  same  model   •  Can  be  confusing:  who‘s  taking  responsibility?  Can  lead  to  back  loops   MULTIPLE  COMPONENT  HIERARCHIES  (II)   Component 3 Component 2 Component 1 props props callback Component C Component B Component A props props callback Model 1
6. REACT  MEETUP  HAMBURG   FLUX  
7. „ApplicaNon  architecture  for  building  user  interfaces“   •  hGp://facebook.github.io/flux/   •  Design  paGern,  not  a  framework   •  Various  implementa,ons  and  interpreta,ons   •  Not  ,ed  to  React     Introduces  unidirecNonal  data  flow   FLUX  
8. Component  triggers  an  AcNon  using  an  AcNonCreator   UNI-­‐DIRECTIONAL  DATA  FLOW  -­‐  1   <button onClick={()=> { UserActionCreators.addUser(...); }} />   Component ĐƟŽŶ trigger
9. AcNonCreator  sends  AcNon  to  Central  Dispatcher     UNI-­‐DIRECTIONAL  DATA  FLOW  -­‐  2   addUser(name) { Dispatcher.dispatch({ type: ‘USER_ADD_ACTION‘, payload: { user: name } }); }   (UserActionsCreator) Component ĐƟŽŶ Dispatcher trigger pass into
10. Dispatcher  forwards  the  AcNon  to  Store     UNI-­‐DIRECTIONAL  DATA  FLOW  -­‐  3   Component ĐƟŽŶ Dispatcher Store trigger pass into dispatch to
11. Store  processes  AcNon  and  emits  a  change  event     UNI-­‐DIRECTIONAL  DATA  FLOW  -­‐  4   handleAction(action){ if (action.type===‘USER_ADD_ACTION‘) { this.users.push(action.payload.user); emitStoreChangeEvent(); } }   (UserStore) Component ĐƟŽŶ Dispatcher Store trigger pass into dispatch to inform
12. Component  receives  event  and  updates  its  state   UNI-­‐DIRECTIONAL  DATA  FLOW  -­‐  5   onUserStoreChange() { this.setState( {users: UserStore.getAllUsers();} ); }   Component ĐƟŽŶ Dispatcher Store trigger pass into dispatch to inform
13. Note:  different  implementa4ons  interpret  differently     FLUX  ELEMENTS  IN  DETAILS  
14. „Regular“  React  component   •  Triggers  an  ac,on   •  e.g.  on  user  interac,on     •  Listens  to  one  or  more  Stores   •  Derives  its  state  from  Store   •  Update  children  from  render()  method         Controller  Component   •  Top-­‐level  component  should  be  the   only  component  interac,ng  with  Flux     COMPONENT   ĐƟŽŶ ŽŵƉŽŶĞŶƚ ŽŵƉŽŶĞŶƚ ŽŶƚƌŽůůĞƌŽŵƉŽŶĞŶƚ props state props ^ƚŽƌĞ listen dispatch
15. AcNon   •  Represents  seman&c  event  happend  in   the  app   •  Has  an  iden,fying  „type“     •  Contains  informa,on  what  happend   (payload)   •  Triggered  by  Components       AcNonCreator   •  Factory  for  Ac,ons   •  Ensures  integrity  of  ac,on  object,     •  Seman,c  methods     •  Pass  Ac,on  to  Dispatcher     ACTION  and  ACTIONCREATOR   Component ĐƟŽŶƌĞĂƚŽƌ addUser(...) dispatch ĐƟŽŶ Type WĂLJůŽĂĚ ŝƐƉĂƚĐŚĞƌ
16. •  Pure  technical  component,  no  business  logic   •  Only  one  Dispatcher  in  your  applica,on  (singleton)   •  Forwards  Ac,ons  to  all  registered  Stores   •  Works  synchronous         DISPATCHER  
17. •  Contains  the  business  logic  for  a  specific  domain   •  Conntect  to  the  central  Dispatcher  via  callback  method   •  Process  only  Ac,ons  they  are  interessted  in  (eg  filter  by   type)   •  Emit  events  aZer  changing  model       STORE   Store process Component Component Component ĐƟŽŶ ĐƟŽŶ ĐƟŽŶ event listen update
18. Very  flexible  scenarios…     UNI-­‐DIRECTIONAL  DATA  FLOW  -­‐  EXAMPLES   Component ĐƟŽŶ Dispatcher Store trigger pass into dispatch to inform
19. ...Ac,on  can  be  dispatched  to  mul,ple  stores   ...A  component  can  listen  to  mul,ple  stores...   UNI-­‐DIRECTIONAL  DATA  FLOW  -­‐  EXAMPLE  1   Component ĐƟŽŶ Dispatcher Store Store trigger pass into dispatch to dispatch to inform inform
20. ...Mul,pe  components  can  listen  to  same  store,   working  on  same  domain  „model“...   UNI-­‐DIRECTIONAL  DATA  FLOW  -­‐  EXAMPLE  2   Component Component ĐƟŽŶ Dispatcher Store trigger pass into dispatch to inform
21. ...“external  events“  (e.g.  response  from  server)  can  trigger   ac,ons   •  Flow  is  s,ll  the  same   UNI-­‐DIRECTIONAL  DATA  FLOW  -­‐  EXAMPLE  3   Component Component ĐƟŽŶ ĐƟŽŶ Dispatcher Store trigger trigger pass into dispatch to inform External
22. Useful  when  working  on  same  model     Defined  flow  of  data   •  Easy  to  track   •  Recordable   Lots  of  new  vocabular   •  eg:  what  is  the  shape  of  a  Store?   Many  implemenaNons   •  No  „standard“  implementa,on   SUMMARY  
23. REACT  MEETUP  HAMBURG   THANK  YOU!   Slides:   tbd