React Chicago - Building with Flux

Have you been wondering what the Flux architecture craze is all about? Maybe you’ve had a chance to play around with some of the implementations, but are wondering what applications look like as they grow beyond a todo or chat app? Perhaps you’ve built some large applications using the architecture, but are curious how others are applying the patterns? Join us on Wednesday, July 22nd at Slalom as Phil MacCart shares his team’s experiences in engineering a customer-facing web portal using React and the Flux architecture.

Phil MacCart is a solution architect at Slalom Consulting, focused on building out customer-facing products for the modern web. After an initial “WTF” reaction to the React introduction at JSConf in 2013, the simplicity of the library drew him in; he’s been building with React for the past year now.

Transcript

6. From  the  flux  website   -­‐  Applica;on  architecture/pa>ern,  not  specific  to  React   -­‐  Complements  react’s  composable  view   6  
7. Basic  Flux  architecture  –  ac;ons  come  into  the  system  from  either  external  sources   (asynchronous  events)  or  from  views   Dispatcher  translates  ac;ons  into  events,  feeds  them  into  the  store,  which  no;fies   the  views   7  
8. Views  are  composable   -­‐  Easy  to  write  small,  isolated  views,  then  pass  data  down  as  props  to  child  views   -­‐  Data  shouldn’t  need  to  flow  back  up   8  
9. Stores  hold  most  of  the  business  logic,  along  with  all  applica;on  data  and  state   Each  store  deals  with  a  par;cular  problem  domain   -­‐     9  
10. Stores  listen  for  events  fired  by  the  dispatcher,  filter  over  the  events,  and  decide   what  to  do  with  each  event  coming  in   10  
11. Dispatcher  will  send  ALL  events  to  the  stores  that  have  added  callbacks     Stores  are  responsible  for  looking  at  the  event  types  and  understanding  specific   events  they  are  interested  in   11  
12. An  ac;on  creator  module  represents  an  API  for  crea;ng  related  ac;ons.   12  
15. Pure  func;ons:  1.    The  func;on  always  evaluates  the  same  result  value  given  the   same  argument  value(s).  The  func;on  result  value  cannot  depend  on  any  hidden   informa;on  or  state  that  may  change  as  program  execu;on  proceeds  or  between   different  execu;ons  of  the  program,  nor  can  it  depend  on  any  external  input  from  I/O   devices  (usually—see  below).  2.  Evalua;on  of  the  result  does  not  cause  any   seman;cally  observable  side  effect  or  output,  such  as  muta;on  of  mutable  objects  or   output  to  I/O  devices  (usually—see  below).   15  
17. View  component  hierarchy   17  
18. Data  connec;ons  –  clicking  a  folder  needs  to  update  the  message  list    -­‐  clicking  a  message  list  item  needs  to  update  both  the  message  AND  the   folders  view  (poten;ally  marking  the  item  as  READ)   18  
20. We’ve  favored  keeping  our  API  requests  contained  within  the  store,  par;cularly  to   assist  with  cases  where  an  ac;on  may  or  may  need  need  to  issue  an  API  request   -­‐  example:  cached  data   20  
22. Ac;ons  represent  something  that  HAS  happened  (bu>on  clicked,  message  sent,  etc.)   22  
23. For  items  that  are  HTML  and  CSS,  with  no  interac;vity,  you  probably  don’t  need  a   React  component     Excep;on:  HTML  +  CSS  structure  is  unreasonably  large   23  
24. Stores  are  singletons  –  don’t  let  views  just  require  stores  and  import  own  data   24  
25. Stores  can  hold  more  than  just  a  model  or  collec;on;  they  can  also  hold  the  UI  state   associate  with  the  UI  representa;ons  of  those  models     25  
26. Favor  having  an  onChange  and  an  onError  event  callbacks.         Always  refresh  state  of  ENTIRE  component  when  a  change  event  is  fired   26  
27. On  changes,  views  should  ask  the  store(s)  for  EVERY  piece  of  data  they  need,  rather   than  just  the  specific  piece  of  data  they  think  might  have  changed.   27  
28. When  change  events  are  fired  from  the  stores,  reload  en;re  view  state   28  
29. When  in  doubt,  favor  keeping  all  applica;on  state  within  a  store.    Some  excep;ons   could  exist  for  component-­‐specific  state  (dialog  posi;on  on  a  screen,  widget  size,   etc.).    For  more  complex  interac;ons  (eg:  displaying  a  loading  spinner  while  saving),   consider  firing  mul;ple  onChange  events  from  your  store.   29