Frozen @ H O LT B T – B R I @ N H O . LT P R E V I O U S LY C U R R E N T LY
Indiana Jones and the Last Crusade W H AT I S R E A C T ? • React is open source library that came out of Facebook. • It is a view layer that allows you to create components that are in turn composed of other components. • Its greatest contribution to the JS landscape is the solidifying and popularizing the concept of one-way data flow as applied JS user interface construction. • It does use a virtual DOM to achieve great performance in the browser. While a really great feature and well implemented, this only makes using React feasible, not desirable.
The Dark Knight “ S TAT E I S T H E E N E M Y O F A M A I N TA I N A B L E A P P. ” — B A T M A N
Kill Bill Vol. 1 S TAT E V S P R O P S • React has two concepts of data access in a component: state and props. • Props are “things” passed down from the parent to the child. Try to use props as much as possible and keep as little state as possible. Props are immutable. • State are kept in a component and can only be modified in that component. State is mutable. Using state should avoided where possible, opting to use as little state as possible.
Skyfall O N E W AY D ATA F L O W • React views are made of a component, which is in turn made of components, which is in turn made of up of more components. Turtles all the way down. • Data only flows from the parents to the children. • Children thus only have the logic to display the data, not modify it. • Children also handle events and then inform parents via callback or events. Parents then modify their own state. • Thus when you unexpected behavior it can only live in a select few places. This comes at the cost of being a bit verbose.
The Lego Movie S O W H AT D O I D O W I T H D ATA I F R E A C T D O E S N ’ T C A R E A B O U T I T ? wtf state
The Life Aquatic U P T O Y O U • Use props and state; store much of the state in the root component. I typically do it this way unless I have reasons not to. • Need cross, unrelated component communication? (think Facebook’s notification bar and how the number goes up and down via several different actions) Use an event emitter! • Need to share state/data across a fairly big app? Use Flux. But Flux is typically overkill for most small-scale apps / widgets. • I wouldn’t recommend shoe-horning React into MV* frameworks like Angular or Backbone. It can work but I found it easier to stick to the idiomatic ways of approaching those MV*s.
Indiana Jones and the Temple of Doom lolwut M A S H I N G T O G E T H E R M A R K U P A N D J AVA S C R I P T S ? I S N ’ T T H AT A B A D I D E A ?
2001: A Space Odyssey M U S H I N G T O G E T H E R C O N C E R N S • Being used to MVC from the server, a lot of us get uncomfortable at the idea of mushing together concerns. I certainly was. • What is good for the server is not good for the interface. Separating models out from controllers allows great code re-use for server. It’s a mess on the client. • Instead it makes sense to thinks of things in terms of components, which are made up of behaviors (or containers) and layouts. It often mimics your markup.
Star Wars Episode V: The Empire Strikes Back T O O L I N G • We’ll be using a few noteworthy tools. Let’s briefly cover that: • Gulp – Simple build system. It’ll run our build. • Babel – We’ll be using it to transpile our ES6 JSX to ES5. • Browserify – We’ll use it to package our app together so it can be used in the browser. • Koa – An awesome node/iojs server that allows you to uses ES6 generators for middleware. If you’ve used Express it should feel very familiar. • iojs – JS on the server. I’ll be using v1.6.