Step 1: get Genymotion to use Charles (copied from this ref)

In your Genymotion Android emulator…
Settings -> Wifi -> Press and hold your active network
Select “Modify Network”
Select “Show Advanced Options”
Select “Proxy Settings -> Manual”
Set your Proxy to: 10.0.3.2 (Genymotion’s special code for the local workstation)
Set your Port to: 8888
Press Save

Step 2: Add SSL endpoint inside Charles

Charles -> Proxy -> SSL Proxying Settings, add the URL endpoint

Step 3: Add SSL certificate inside Android

Inside Genymotion, using Android’s browser, visit http://www.charlesproxy.com/getssl and install the certificate.

Step 4: There is no step 4.

React Native

3 pillars
– Touch handling (biggest difference between native and mobile web)
– Native components (there is a lot existing native components, and the mobile web framework should provide something comparable)
– Style & layout ()

Native Components:
RKView extends from UIView. It converts DOM commands to native. The only work done in the main thread is setting the view, all others are offloaded.

Internally, it run a real JS engine, using JSCore this time. All js modules that don’t depend on the browser will work. Showed running js remotely in Chrome, with websocket communication between iOS simulator between Chrome, could run js remotely in the future, or run js remotely in the server. Crazy idea: what if server-side render native views..

-Styling

React: CSS in JS, speakerdeck.com/vjeux/react-css-in-js

Style Declaration in JS with Inline Styles

Instead of separating technologies (JS/CSS), we need to separate concerns

Layout: top,left, width, height
IOS -> manual mode -> auto layout (constraint solver)
CSS -> margin, padding, border
Flexbox -> life changing

NO browser in native env -> need to reimplement a subset of flex box in ReactNative
Generate random tests -> send it to browser and ReactNative implementation -> compare and extreme TDD

Only implemented a subset of Flexbox

iOS? The bridge between JS and Objc-C is async, batched, seriablizable. Async is very problematic.

Also ported the flexbox implementation in C and Java, and open sourced at https://github.com/facebook/css-layout

Web components
Web components -> html elements encapsulable and portable

Intro to custom elements / Shadow DOM

web component for react
– small
– extremely encapsulated, no side-effect
– stateless
– performant

Custom events need to attached and detached manually

The future
– custom attribute support
– custom event

Lee Byron, Immutable Data in React & Flux

immutable.js

How? Why?

Persistent immutable data structures

persistent(not related to write to disk, but leave the old one unchanged)

Isn’t deepclone really slow? Well, isn’t re-render the whole UI slow?

Interface vs implementation

implementation – structural sharing – directed acyclic graph
directed – references
acyclic – no going back

an version of DAG – Index Trie (List), Hashed Trie (Object)

Legendary people:
– JCR Licklider
– Alan Kay – ‘the early history of smalltalks’
– Phil Bagwell
– Rich Hickey – Clojure – Simple made easy – 2011

Mutable objects are complicated in identity, time and space. Immutable data removes complexity

The many mutators problem. But what changed?
– ES7 – Object.observe(), only one level deep
– Immutable change tracking and memoization

Om is faster than React! Immutablity has constant penalty(3-5x) with log(n) memory but can change some ops from o(n) to o(log(n))

Beyond the DOM: How Netflix plans to enhance your television experience #

Jafar Husain, cross-team leads for UIs

Three things you don’t know about Netflix:
1. loves js, runs thousands of devices, and js has the reach. A/B testing with js can break out the App Store constrains
2. super secret TV platforms. Netflix TV platform. 2-3 years ago, webkit + web app in the TV. DOM is slow.
3. love React.

Netflix TV platform – Gibbon
– get rid of DOM. Use widget object model instead of DOM
– use js instead of js/html/css
– Web is different from TV.
Flow layout -> absolute position
many types -> one type
400+ props -> 25 props
sync -> async
inherited styles -> explicit styles

Gibbon on HTML canvas
– three UIs(mobile.js, web.js, tv.js) in 2013 now two UI (mobile.js/web.js into one, tv.js use Gibbon)

Love react
– one year now
– two reasons, performance and simplicity(one way data flow, server side rendering, even for TVs)

The challenge for team – use React with Gibbon in 5 days

Option one – fork React
Widget Adapter Mixin, convert widget to DOM-like

DOMPropertyOperations
ReactDomComponent

Create markup string
– mountComponent
– createMarkupfor

Object.assign??(ES6)

React Fork:
– dev days 2
– forked loc 67

Option two – spoon react
– monkey patch
– react-art
– react-ios
– react-pixi
– react-three

React for total different

new mixin based on ReactMultiChild
overwrite
– moveChild,
– createChild
– removeChild

Continue working on the TV version of React. Netflix likes React the blog post. RenderToCanvas is closed source, but react-art is a good starting point.

Zach Nation, Dato

Dynamic Web UI

Data visualization (Graphlab Canvas)

two things
– turn data into visual elements
– handle rendering

Build a predictive application
data -> relevant info -> build a model -> deploy the model

Human beings are good at visual pattern recognition

Example: bitcoin transaction

21G data, sequentially arranged, 45M transactions

Challenges:
– Large data to visual elements
– High level of interactivity
– Maintain state across the whole-app UI

Pipeline:
Data -> aggregation -> d3.js (produce visual elements) -> rendering (react.js)

– compute close to the server
– Flux on the server, replace dispatcher with XHR / WebSocket

Cons: it’s a single user server

Scalable aggregation
– binning, histogram in 1d and heatmap in 2d
– sketch data structures
– constant memory complexity
– produce results incrementally (streaming). Important for UI/UX
– send results to client periodically

Example:
Server owns the state -> web socket -> component setState -> re-render

Visual elements correspond to React component
– text values are data
– D3.js complement React

Three parts of d3 conflicts with React.js
– Selections(d3 core)
– Transitions(d3 core)
– d3.behavior

Chose a render target
– svg
– canvas
– react-art
– webgl
– ios
– android

Considerations
– number of visual elements (canvas better)
– animation
– level of interactivity
– browser support

Svg vs Canvas
– SVG: css styles, css animations, DOMEvents
– both: 1000 or fewer elements
– Canvas: 1000+ visual elements

The Graphalab canvas
– 100% React rendered with stateful-server
– up to 1TB data streaming down

Server – Aggregation

Client – React.js

github.com/znation

Om – David

Closure language
ClosureScript -> dialect of Closure targets JavaScript

Context:
– unfamiliar != complex
– big != complex

React as platform
– Platform, not about solution, about process
– Pick bricks as the tool, build both regular house and amazing buildings

The reason: other frameworks pick mutability, React works with both mutable and immutable data. Mutability should be an implementation detail

OM, based on a paper by Alan Kay

Design
– immutable app state
– async rendering via requestAnimationFrame
– jumps to any point of time with respect of application status
– modularity

How do you hide data from components that they shouldn’t know yet still keep it global..
– lens or windows, only returns a slice of the global state to the component
– this solves 60% of the problem

Reference cursor, same cursor but observable
– same as event listener, just observe
– allow OM components to listen on data changes

There is nothing fundamentally wrong with observation.
– after normal render of the component tree from the root, walk list of reference cursors to see if they are changed. if changed, force update
– CircleCI demo, 10 – 15k line of closure script

Interesting UIs are inherently complex…

Immutability identify sources of incidental complexity

Bad part:
– custom tag that isn’t React key or constructor function
– expose React component tree as data to support custom tree transformations (like a compiler, expose the tree as data)
– regular JS classes

Why React?
– not because of virtual dom
– but because of DOM virtual machine / UI virtual machine

Flux Panel by Bill Fisher

Relay are more for big teams with big apps. Flux is for a much wider audience. There is a migration path from Flux to Relay. You could have both of them in the same app.

Data fetching:
– Only call getData in the store, 100+ stores, and 60+ need to fetch data. Moved the data fetching into the store, if not there, the store will get it and put it to the store cache. When updating, it is nice to have all data fetching in one place. Consumers of the store don’t have to change.When building new request for data, sometime you need the existing data which is exactly in the store. It is natural to construct the request from within the store.

– Everything goes through the data the same way. All of our writes are in the action creator. Action creators are async, promised based. Good for optimistic updates. Why in actions? Because different stores might need the result of the action.

Kyle:
– performance in large app (106 stores)
– dispatcher is sync
– interface becomes laggy for few reasons
– have two stores responding to the same action, then both store will emit a change, when controllers listen to both stores, it will re-render twice for the same action.
– when loading the page, 200+ actions, when change, 80+ actions. The easy optimization is to debounce the call based on the dispatch loop, wait for the loop finish. 75% reduction in # of actions.

Very few dependencies in store (90+ stores)
– when store has lot of dependencies. Components are responsible for dependencies. Component will get data from store A and send it to B. Component will declare that for this field in my state, here is the data that field depends (graphQL). When any prop changes, figure out whether the depending data changes.

Large app:
160+k loc, 10+ engineers
700+ components
– Component is the best way to maintain a large codebase.
– Keep store from each other. Thread store and Message Store. Keep data separate. Normalize all the stores, similar to a database.

Isomorphic flux
– soudcloud store singleton
– yahoo store instances

Take actions, call them on the server, and hydrate the store on the server. Make store classes and fill their instances per request. Ability to test easily.

Dehydration and rehydration. Create store instance per request, has a request context per request, has a dispatcher, at the end of execution, gave all the store on the server, let’s dehydrate and serial down the client, and rehydrate the app on the client

Singleton store. You could run into con-current issues. We don’t use flux to fetch data on the server side, a helper do it and pass the data to the action. A pure action that based on the same data. The client will take an extra step, first pass, and the second pass for client specific stuff.

Andres, Scala backend, browserify the app and get a platform agnostic version. Run the app in a Java based JS runtime(?), and spit out html. Very render-oriented approach.

Michael, stateful, mostly fetching logic in the actions

Airbnb
– migration from Backbone/handlebars to React
– biggest app is mange listing app, allowing host to manage properties
– Pick a part of the backbone view and replace it with React
– Wrap model/collections with store, introduce actions. A thin wrapper!
– Compared to backbone, now we have clear entry point for data fetching

What is the dispatcher in Airbnb:
– AppModel(from Backbone days), reuse the global dispatcher as the flux dispatcher. We inject the AppModel into different places.
– One thing missing is the waitFor method. So far we haven’t had any need for waitFor, but might need it in the future.

Optimistic update and error handling:
– maintaining a clientId?
– actions queue in Relay is interesting
– When merge the update without confirmation from the server, you lose the previous state. Actions queue keep a separate queue of actions, if an error comes in, can take the action out of the queue, if confirmed, can take action out of the queue. All views get data from store + queued updates.

Routing:
– route at the store level
– no change route or change route methods
– route store will change, will decide what component need to render at the root component.
– route store becomes the ultimate store!

Q: decouple actions from store?
A: container component + UI component. container’s job is to talk to store and get the state, no state in the UI component.

Codecademy’s approach to component communication by Bonnie Eisenman

– communication needs
– what we did
– what could be better

Rebuild six month ago.
https://www.youtube.com/watch?v=U5yjPG5mHZ8 Why react from codecademy?
– server side rendering

learn react
– sample code from khanacademy
– react tutorial

Communications:
– callbacks everywhere

Comm need:
– pass state changes to siblings, cousins
– adjust to changing comm targets
– A lot are responding to client actions in the client side

What we did:
– Adapters, always has one,
– Major components, listen to events broadcasted
Major component -> brodacts – > adapter (<=>backend) – > set state

Major Components:
– Tester
– Browser
– ContentEditor
– CodeEditor
– Instructions

Adapter = state dispatcher

Create adapter based on what components are present. When components changes, re-generate adapters.

Defining an adapter:
– Files for any combination of components
– Used to do mixins

Under the hood:
– adapter.js
– create, destory, handle,
– create.js
– only 120 loc
– hook into componentDidUpdate

What are we doing wrong?
– outside manipulation of state???

Adapter vs flux?
– no concepts of stores. Getting data from server is not a pain point
– major components – controller views

Food for thought?
– just the view?
– how should a data flow pattern like Flux be treated in the React docs
– what do you want from your data flow architecture?

Code sandboxing:
– each user has their own box (docker I assume)

Static typing with Flow and TypeScript, James Brantly from AssureSign

Why need type?
0 * ‘123′
‘0’ + ‘2′
– good at first pass
– if add first:number, second:number , then get type checking at build time

Demos
– webpack
– jsx loader

TypeScript:
– it doesn’t understand JSX (stop using jsx / fork TypeScript / hack)
– hack, make JSX a string, React.jsx(“), jsx add a precompile step, convert React.jsx(`

’) to React.createElements()

– syntax changes from js to ts:
— import instead of require
— exports instead of module.exports
— TypeScript definition files, similar to c header files, _references.d.ts
— references path at the top of each file
— remove mixins because ES6 classes don’t support mixins

Flow
– native react support
flow init -> create flow config file -> fix require calls,
flow (cli)
annotate /* @flow */
return any as type annotation

– jsx loader ? strip types

Integrate with flow is much faster than TypeScript

Flow
-understand props
-understand props in jsx

Flow:
– native react
– better type inference

TypeScript:
– works on windows
– lots of definition file

typed-react

Q&A

CSS layout, inline styles, this version is really for react-native

Q: react in other languages?
A: Facebook iOS components, based on the same React idea, but in objective C

Q: rendering mechanics but not enough server sider rendering?
A: Relay has different modes. One mode is js + payload; the other mode is html + payload. The server side render is not designed that way. We can avoid auto-binding.

Q: props, state, context?
A: Diff between owner and parent. Owner creates the element. We are changing it to parent based. The concept of context will stay.

Context comes from XHP, several use cases:
– viewer, who are you logged in; used to be a global, but then viewed as your friend. Then who is logged in vs who is viewing? Then passing a new global to a sub tree.
– logging data
– focus and selection are two global UI states, that could be implemented as contexts!!! Don’t use it to pass the props down.

ReactNative, when there are new iOS and new Android, what to do?
– two ways, either wrap or reimplement. For example, the tab bar at the bottom of the Facebook page is a reimplement.

ReactNative?
– not only fast, but also a better / flexible app. At least better declarative API
– can add new functionalities

Views exist in one platform?
– Transfer from one to another

Mixins?
– Mixin is not part of ES6
– 99% is adding subscription to the external data
– Continue use mixing until there is better way

Webpack?
– we don’t use for Facebook.com
– dependency manger
– trans-compilation
– our packager use machine learning, very fancy packager
– 90+% we are hitting cold caching…
– React Native is bundling js for developer experience

Responsive?
– In Relay, defer query, mark the comment box as optional, and it will come down later.

ReactNative?
– rocksdb for caching,

SurveyMonkey?
– cross browser render in web view and web
– keystone.js

div -> <View />
span -> <Text />
img -> <Image />

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

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

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

{
id:
name:
}

->
{id
name
}

node(1572451031){
id,
name
}

//root call node(){}

node(1572451031){
ide,
name,
birthdata {
month,
day
},
friends.first(1){
cursor,
node {
name
}
},
friends.after(cursorId).first(2){cursor, node{name}}
}

statics:{
     queries: function(){
      return graphql`
     User {name, mutual_friends{count}}
}

}

//Composition:
${ProfilePic.getQuery(‘user’)},
${FriendInfo.getQuery(‘user’)}

mixin -> Authentication
Authentication
willTransitionTo(function(){
 if(not logged){
     Login.attemptedTransition.
     transition.retry();
}
})

function getPhoto(){
  get from cache
  if(){
    get from db
    add to cache 
  }
}

new Intl.NumberFormat().format(1000)
new Intl.DateTimeFormat({
     month: ‘long’,
     day: ‘numeric’,
     year: ‘numeric'
}).format(Date.now())