React.js Conf Notes – Day 1

Christopher Chedeau / Tom Occhino – Keynote
Where did React come from?
– Born at Facebook Ads Org. Building a bunch single page apps. Pain point: cascading updates -> unpredictable code
– Hypothesis: (data) => (view), just a functional transformation. Every time the data change, re-render the entire view
– Initial reception among Facebook engineers: everyone is ‘this is so fun, but might be slow’, but ‘someone is going to make it faster’, then use it on the like/comment box inside
– After instagram was acquired, Pete make React opensource-able
– 2013 jsconf debut. Feedbacks are “huge step backwards” / “Rethink established best practicesTM”. To make it interesting, Pete Hunt gave a talk titled “React: Rethink best practice”
– coming from php or XHP. Key features are composable and approachable
– auto escaping
– composable
– do all the necessary data fetching
What makes React so powerful?
– Virtual DOM?
– Server rendering? (codeacademy picked React for this reason)
– Descriptive warning?
– Custom events system?
His take on why React is powerful
– React wraps an imperative API with a declarative one. In other frameworks, you use imperative code; but in React, you use declarative code. Easier to read and maintain.
– The key is Declarative
– Declarative -> predictable. The power of looking at the code and being able to change it with confidence.
– Predictable -> confidence -> reliability
– “Reacts’ real power lies in how it makes you to write your code”
Components are the fundamental building blocks of our applications!!!! (I agree)
Paper is cool native app.Why not able to do it in a web app?
Basically native environment is more powerful
– ability to parallelism work (async render / web worker doesn’t work)
– sophisticated gesture handing (native good / web not much)
– access to native capabilities ()
The cost is the native environment is more hostile
– native environment is imperative
React Native
– iOS and Android
– Everything on screen is native, but the underlining is completely controlled by JavaScript
— existing solution is sync waiting for js
— better solution is async, and batched
— converting DOM apis to native APIs
div -> <View />
span -> <Text />
img -> <Image />
– putting js in background thread, async display, never blocking the main thread
– Facebook Group is a mixture of native and React Native. Open Source it soon
We don’t want to “write once and run anywhere”!!! Instead, “learn once and write anywhere”. The same team can write iOS one day and Android the next day following the same principles.
What happens next???
Fundamentally change how people think about JavaScript / JavaScript Framework. From Object.observe to immutability

Brenton Simpson – Tweak your page in real time, without leaving the comfort of your editor

Rethink the entire workflow – ebay. Mobile, not simulation, real hardware
– Live change styles Everyday use a tablet to show 3 screens of iphones
1. from script tags to modules. Endorse web pack. Web pack is awesome blah blah blah ***
2. Don’t reload, replace
Component -> Pops -> Result
React makes you can call render() all the time
Replace the component with another component
Use React-hot-loader, hot module replacement
3. Point your device
– use tools Charles and use DNS spoofing
4. Stop repeating your sever
– what’s role of server? To provide the data to the app.
The role of client? To render the data to UI.
The API is platform agnostic.
Exact same JSX codebase renders everywhere
– difference between server-side and client-side rendering
Titles(in html on server, in js on client)
Links(complete page refresh on the sever / no page refresh on the client )
Data scope(sesession oriented vs client oriented)
– Ambidex
– First render on the server, subsequent pages on the device
– Experimental, <6 months old, needs test,
– The basis for everything web in eBay lab
– Being developed in the open
– test on real hardware with a proxy like Charles
– serve is api
Q: Server side singletons?
A: URL tells server what data should be fetched. All the data should be determined by the URL! But haven’t solved the problem / sessions
Q: SOA, server fetches from other services? should client fetch all those services?
A: Reflux

Gurdas Nijor – Unlocking the structure of your React applications with the AST

Static program -> dynamic process
Static nature of React
Static analysis -> analysis based on the code
What makes static analysis difficult?
– In Backbone view, this.$el can be modified at many locations, hence the rendered output is unknown.
– External dependencies,
What makes static analysis easy?
– React component self-contained
– f(state, props) => output
Three ways of using static analysis (only show one below):
– instrumentation of an application, a common theme in CI
– Demo of todo MVC live streaming of changing props
Main Section -> props -> TodoItems
A component wrapper will wrap TodoItems and publish changed to EventEmitter
Fully instrumented meaning wrapping all components
But how do we generalize this transformation?
Source-> Parser -> tree -> Code generator -> output
Source -> Parser(esprima) -> AST -> Code generation (escogen) ->
AST tools:
– Traversal / Query (estraverse / esquery)
– Fragment Parsing (esprima)
– Builder API (ast-types)
– Templates(estemplate)
– Literal
Power of this tool:
– 3D transform of react components
Package transformations:
– web pack’s concept of loaders
– inject runtime dependencies
– invariant -> build time properties
– a way to instrument React applications
– package this transformation for easy consuption

Daniel Schafer and Jing Chen – Data fetching for React applications at Facebook

How do we get the data from the server to the client in the first place???
FriendList -> FriendListItem -> FriendInfo
But each one of them need different data, therefore, there are unnecessary data passing through top of the funnel. If changed FriendInfo, then info has to pass all over again…
How do we come to this?
Changes FriendInfo -> changes every component -> changes the server info
The problem is data leaking. There is missing info -> what data is required for each component
Key idea:
– each component specify its own info requirement
– response Shape
– composition, nested data structures
GraphQL: Facebook client app uses for about two and half years,
– stop writing dedicated endpoints
– abstract data from



//root call node(){}

birthdata {
node {
friends.after(cursorId).first(2){cursor, node{name}}

Data fetching inside Flex
Response shape is specified by GraphQL. Can we specify what need and auto fetch for us?
     queries: function(){
      return graphql`
     User {name, mutual_friends{count}}


Life cycle: Query -> de-duplicate -> Server -> Data -> Store(central source of truth) -> Views
Store is generic, holds all the graphQL data
Relay is the next generation of Flux, rather than components passing props to its children, have components specify its need.
Static view -> query -> server -> data -> store -> views
– Colocation: query and view are specified in the same component
Pain point -> change one thing (over fetching and under fetching)
php -> parent component -> child component
Examples of Relay:
Relay: add one filed in the query and in the render method
this.setQueryParams({count: this.queryParams.count + 5});


     queryParams: {count: 10}
Query validation:
– graphQL provides schema to verify at transform time
– Adding comments
– Take updates and merge and update the central store
– Relay, subscription updates at the component level
Optimistic updates:
– seperate queue for updates
– keep it in the queue until the server confirms
– the error handling is built automatically
Error handling:
Response out of order:
What is next?
– Experimental
– OpenSource graphQl and Relay as soon as we can

James Long – Communicating with channels

– Explain channels
– Integration with channels
– Flux
Talked about js-csp and live demo. (unable to take meaningful notes since I don’t know enough about this topic)

Michael Jackson – Removing User Interface Complexity, or why React is awesome

Michael – OnDemand Valet serivice in LA / mustache /react-router
Removing User Interface Complexity, or why React is awesome
Flow is ember the biggest strength
PHP partials -> assemble the case
Ember -> declarative composition inside each route
“If your user interface is nested, your routes should be nested”. But NestedRoutes != nested URLs
URLs (Ember’s philosophy)
– URL should capture all the information related to that route
– URLs should be part of your design process
– when URL changes, what happens…
– A common use case: remember the destination, redirect to login, then continue to the original destination
– Transition redirect and transition retry
– willTransitionFrom. When user is trying to leave an un-submitted form, prompt the user to confirm
– transition.abort();
mixin -&gt; Authentication
 if(not logged){

The future
– ES6 classes
– Not just JSX
– Sub-routers???

Pete Hunt – The future of JavaScript layout systems

… is probably not GSS (great style sheet). Interesting abstraction, but solvers are unpredictable.
Full-Stack Flux
– A review of Flux
– The current state of the backend
– How Flux can save us
A review of Flux
– Facebook Chat, ship fast and maintain reliability.
– Talk about the problem, how adding new features adding more code to maintain
– Shared mutable state is the root of all evil. The alternative is Observable
– Flux can scale to answer many questions
What about backend?
function getPhoto(){
  get from cache
    get from db
    add to cache 

Similarly, caching some derived data ?( derived data)
What is a Flux Store?
– Reduce() and emit a change event
– Derived data (cache/search index/data warehouses)
– Your app is the derived data
The idea:
Actions -> RabbitMQ(dispatcher) -> getPhoto(photoId) (Store)
                                \——> getMostLikedPhoto(photoId)
 |                                              |
app  <- dispatcher    <-      Action
Message queue (equivalent to a dispacher, but distributed)
Advantages of messageQ
– ***
– has all the state
– most important, manage the tradeoff
Choose the best data store for your question
– schemaless or not
– write
– read
– query flexibility
– costs
– durability
Closing the loop
– Rather than asking the store all the, subscribe to queries on db
Things don’t work
– communication between stores, in particular waitFor()
Option 1: shared DBs between two stores, image classifier to mark whether an image should be blacklisted
Option 2: Enrich data
– image object -> slow running classifier -> enrich the action and add isBlackListed field
– Directed async graph, hook the output of one store to another store
– Forget about strong consistency, adopt an eventually consistent system
– Kafaka should be a better choice
Stream processing on the server, Apache
Recommend to watch “turning the database inside out”
– don’t know what question we need to answer so far.
– it’s not too often that we need multiple stores to answer one question. If two stores are coupled too much, then merge them.

Jason Bonta – Building performant React apps

Works for Facebook Ads. Ads creation gives birth of React.
Ads Manger need to be simple yet powerful. Simple for most users who don’t think them as advertisers, they are small business owners. Powerful for enterprise users, should have native look and feel for tens and thousands of ads.
Ads Manager
– css perf
– GPU acceleration
Optimization ideas:
– props and state
– pure components, the render is only based on props & states
– re-render is the key, shouldComponentUpdate
– mixins: [PureRenderMinx], separate your pureComponents from others
— data comparability, only shallowEqual, problematic for Date() or even functions
— inspired by how people return goods at the brick & mortar store by verifying receipt and sealed product
— data comparability, from a single source of truth (sealed object)
— immutability / immutable.js => referential equaly => fast
Controlled scrolling example
– <Container><Table /><Container />
– event hander on the wheel hander
– components move the content up and down -> change offsetTop
– Separate table code from the scrolling container code -> separation of concerns -> also perf. Scroller changes all the time, but the table code doesn’t change much.
Children create deep update trees
– The more nodes, the slower the diff
– If passing props many levels down, then tightly coupled
Children change over time
– Children is not comparable, can’t compare this.props.children !== next props.children
Children are expensive
Independent children
– not relying parents to pass things to children
– PureRenderMixin
– shouldComponentUpdate just return false
Policy inside FacebookAds
– <Container> <Widget/></Container>
– any data fetching component need to be a container. container talks to the store
– Widget just render
– Container vs components. The point is — container is the data layer!!! You got insulation. When you use the containers, you can move them because they don’t depend on anything!!!
Advantage of Container + Widget
– separate data from presentation
– very easy to show them in the component library
– very easy to test
Components are the foundamental building blocks.
Ads manager:
Every single cell is a speperate APP.
– purity, use shouldComponentUpdate and PureRenderMixin
– data comparability (highly comparable data, immutability)
– loose coupling, smaller apps, maintain and performance
– children, expensive and exercise independent (use containers)
<FixedDataTable /> —> open sourced UI component

Eric Ferraiuolo – React.js & i18n

The problem:
– Localization, 1.002’s meaning depends on the locale
– English is only 5.2% speaking and 27% internet users
The i18n problem:
– Pluralization
– Formatting of the date
– 1 people liked this vs Eric and 1,200 more people liked this
– Relative time
The formation aspect of internationalization
– moment.js for dates related things
– i.e. how to format number with 1,000
ES5.1 has
– Intl.NumberFormat
– Intl.DateTimeFormat
– Intl.Collator
– Missing from Safari but can be polyfilled by intl.js
– the usage
new Intl.NumberFormat().format(1000)
new Intl.DateTimeFormat({
     month: ‘long’,
     day: ‘numeric’,
     year: ‘numeric'
– need to cache
– and imperative
In React, React Intl (npm module), declarative
String messages (ICU):
“hello, {name}”
“You’re {age, number} years old”
var msg = `{num Comments, plural, one {# comment}, other {# comments}`
<FormattedMessage message={msg} numComments={1200}/>
Intl Mixin
– Add [IntlMixin] at the top of the app and it will cascade to all children
React Intl
– 7.7k min + gz
– 150+ languages
– English as default
Bigger project, format.js, one of the child project is React Intl, one for handlebar and one for dust and one for ember.
– Format.js integrations
– Format.js Core
– JS Runtime (Int.*)
– ICU (International Components for Unicode)
– CLDR (Unicode Common Locale Data Repository)
Endgame, eventually propose this and add it to ES
– Intl.MessageFormat
– Intl.RelativeFormat
Q:abbreviate numbers in different locale
A:no idea. Data does exist in CLDR, but not implemented it.
Q:i18n and formated HTML string
A: formatMessage with a simple placeholder. If name is to be bold. Pass react element as value
The other way – HTML message component, escape all html and do dangerousInnerHTML

Ryan Florence – React let you say YES

– Personal story. Sold life insurance in Idaho. Got so interested in software that he spent all his down time writing software. First developer job at an agency and the boss commented that “it’s so weird that a developer keeps saying yes.”
– Developers want to say yes, but often says no because of lack of good tools. React let you say yes more often.
– live updating tables, ember memory leak, give up at 100; timeout0, react works but ember/angular broke
– magic move
– react-a11y, react’s declarative nature make the assertion possible
– portal, stop the render tree, use jQuery, then use React.render to build another tree
– router animations, use React
– iTunes, route with openning children
Disclaimer: personal notes. Might misunderstand the presenter.