Skip to main content

JavaScript: React Conf 2017

I went to REACTCONF17. Here's the schedule. Here are the videos. Here are my notes:


Tom Occhino, Jing Chen, and Sebastian Markbage

547,000 users have React DevTools installed.

Facebook has 100s of React Native screens in production.

Facebook uses React for many screens in the Facebook app. You can't tell the difference between what is and isn't using React Native.

He said they're not done with React. They're going to "Innovate in place." There's always going to be an incremental path. You'll never have to rewrite from scratch.

React Native at Facebook


  • Fast iteration
  • Declarative views
  • Cross-platform (and cross application)

They couldn't rewrite the entire Facebook mobile app. Instead, they're incrementally adopting React Native.

Things they focused on:

  • Performance
  • Parity (between iOS and Android)
  • Developer experience

The bundle size of their React Native app is 11MB, uncompressed.

They do API fetches really early, even before all the code has finished loading.

It's now easier to add a new view. You no longer have to rebuild for every platform every time you add a new view.

They build features that are used across apps (across Facebook and Instagram).

During the migration effort:

  • Build relationships
    • Have regular checkins with the teams
    • Give tech talks and hold happy hours
  • Integrate with the native infrastructure
  • Pay attention to the user experience

React Performance End-to-End

The industry has been moving toward client-side technologies.

  • Robust interactivity
  • Sophisticated UX
    • Offline
  • Innovative interface designs

He plugged the "extensible web".

Slow startup time is a problem, both for web and native.

Some people are considering moving more toward the server:

  • AMP
  • Facebook Instant Articles

Some things should be moved server-side.

Only download what you need:

  • Bundle splitting

Cache the last version:

  • Auto app update
  • Service workers

P2P delivery:

  • P2P app updates (really?)
  • WebRTC

Shared distribution:

  • Shared versioning (common set of tools across companies)
  • CDN

Cache artifacts:

  • Bytecode / codegen cache
  • Ahead of time compilation

He said he's going to talk about "another language" (other than JavaScript) tomorrow.

Compile (like Closure compiler):

  • Constant folding
  • Heap snapshotting


  • Smarter algorithms / APIs
  • Optimizing compilers

Try to load and render chunks asynchronously. He talked about streaming responses. Let each component be rendered when it's ready.

Just showing UI as soon as possible is not a good UX because it looks janky. Only display a chunk when the whole component is ready.

Responding to user interaction is always more important than showing more UI.


  • Gestures / animation: 10ms
  • Tap / click: 100ms
  • Network / timer: 1000ms
  • Off screen / hidden: whenever

Scheduling is a core part of UI engineering. Right now, it's too ad-hoc.

Important: That's why they built React Fiber.

He said something about asynchronous rendering, scheduling primitives, etc.

yarn add react@next
yarn add react-dom@next

They're already using it in production at Facebook.

More stuff from the main speaker

Fiber is a new foundation for React.

They're working on an <ErrorBoundary /> component.

They're making it so that you can return multiple things from the same component ;) You can return arrays or strings from render.

React Fiber is completely written in Flow.

They're trying to make the codebase more approachable.

He plugged create-react-app. This will help stop JavaScript Fatigue.

We shouldn't bifurcate the community based on platform boundaries. "One React Community".

A Cartoon Intro to Fiber

Lin Clark from Mozilla

She has a cartoon to explain Fiber.

Fiber will make rendering a lot less janky.

It improves perceived performance and responsiveness.

There's a new reconciliation algorithm.

React's initial killer feature was its virtual DOM.

They're differentiating the reconciler and the renderer.

There's a renderer called react-pdf for rendering PDFs.

There are high priority updates and low priority updates.

Currently, the main thread gets stuck waiting for all the recursive renders. The idea is to render some of the components, and then give up the main thread.

A fiber is a plain JavaScript object. It has a 1-to-1 relationship with an instance. She said something about a "stateNode".

There's a work in progress tree.

There's a stack reconciler. It takes changes from instances, and updates DOM nodes.

  • Phases:
    • Phase 1:
      • render / reconciliation
    • Phase 2:
      • commit (cannot be interrupted)

It can schedule work later. It uses requestIdleCallback.

There's a work loop. Do a little bit of work. Then come up to let the main thread do its thing. It keeps track of what more works need to be done, and how much time is left in the given frame.

There's an effect list.

React is using double buffering.


  • Synchronous
  • Task
  • Animation
  • High
  • Low
  • Offscreen

Lifecycle methods might not fire in the order you expect. With Fiber, you can't guarantee that componentWillUpdate will be followed with componentDidUpdate right away. It might be called twice before componentDidUpdate gets called.

Focus on using smaller units of work. Higher priority units of work will cut in line.

This is cooperative scheduling.

The React core team explained Fiber to her so that she could explain it to us.

Next.js: Universal React Made Easy and Simple

Guillermo Rauch

Next.js makes universal React.js easy and simple.

It should behave predictably and consistently.

Universal = works on the server and client.

He rebuilt Hacker News as an exercise. His demo uses Firebase.

They're been using it at for almost a year.

Minimal convention over configuration.

These are the invariants he expects:

  1. sophisticated apps have many variable entry points
  2. loading more code than necessary is bad
  3. ./pages, ./lib, ./components

Code splitting even makes sense for CLIs.

Having top-level components is good for a UX style guide. It's like Sketch in the browser.

Pre-rendering the layout is a better indicator of progress than waiting for the server to give you a page.

Sometimes you can pull stuff from the client cache.

You can use <link prefetch> to prime the cache when going from one entry point to another.

Hot module reloading (HMR) is a problem if you get too many components.

Next.js improved performance by 10-15X by only watching the things you're working on for HMR.

They have tons of examples, including Redux, MobX, etc.

Inline styles only support a subset of CSS. For instance, you don't have media queries, etc.

They came up with StyleJSX. You can have a style tag in your JSX code near your HTML.

How you use CSS is very variable in the React world. People are doing all sorts of things. If you're building a library, the only universal thing is inline styles, but those are limited.

Next.js has a Babel preset.

Facebook hired the Inferno guy in order to make React better.

React + = ♥

Ben Ilegbodu from Eventbrite

They're moving from Backbone to React.


let comments = this.state.comments // Duplicated "comments"
let {comments} = this.state // No duplication
let author = // Verbose
let text = this.state.text
let {author, text} = this.state // Much shorter

(Note, he's not using semicolons.)

Renaming attributes:

let {author: authorName} = this.state
function MyComponent(props) { // Duplicated props
function MyComponent({children, style}) { // Exactly what you need // No duplication

Spread operator

let newComment = comment = // Oops, accidentally mutated comment too!

You can maintain immutability with the spread operator. This replaces _.assign.

let newComment = {...comment, id:}

You can use it with arrays instead of using concat to append an element and create a new array:

let newComments = [...comments, newComment]

Arrow functions

Replace anonymous functions with arrow functions. This fixes the "this" problem so you don't need to use .bind.

    success: (resJson) => { // Callback with a properly-bound "this"

He covered the various syntactic variations of arrow functions.

const MyComponent = ({children, style}) => (


Replace callback-style programming with promises.

Use the fetch API instead of $.ajax from jQuery.

fetch(this.props.url, {
    method: 'POST',
    .then((res) => res.json())
    .then((resJson) => {
    .catch((ex) => {

You can convert callback style APIs (like setTimeout) to promise-based APIs.

Promise.all allows you to make simultaneous async requests as a single promise.

Async functions (ES2017)

Use normal control flow with async/await.

async _handleCommentSubmit(comment) {
    try {
        let res = await fetch(this.props.url, {...})
        newComments = await res.json()
    } catch (ex) {

In order to implement this, Babel uses generators, promises, and a lot of magic.

He wrote a tutorial:

MobX vs Redux: Comparing the Opposing Paradigms

Preethi Kasireddy

She pronounced it Mob-X instead of Mobe-X.

It's all about opinions and tradeoffs.

Both describe UI as a function of state.


  • View -> Actions -> Store / Actions / Reducer


  • Like a spreadsheet
  • Stores, computed values, reactions, views

Single store vs. multi-store:

  • Redux is single
  • MobX is multiple. How you structure your stores is up to you.

Redux: plain POJOs.

MobX: wraps your objects with observables.

MobX observes references. It keeps track of the data you care about so that it knows when you need to re-render.

Redux: manually tracks updates

MobX: tracks updates; implicit; reactive

Redux is read-only.

MobX lets you read and write to state. It's impure. (Although it has a useStrict feature that she didn't mention.)

Redux: actions required

MobX: actions not required

Redux: you have to normalize your state. You don't want deeply nested data.

MobX: you can keep your state denormalized. You have computed values.

MobX has a much easier learning curve. It's a familiar OO paradigm with magic behind the scenes.

Redux has a functional programming paradigm, and there's no magic behind the covers.

MobX's learning curve doesn't get harder over time.

Redux's learning curve gets much steeper over time.

MobX wins in terms of requiring less boilerplate.

Redux has much better developer tools. Redux's time travel debugging is awesome.

Redux is more debuggable. Understanding what MobX is doing under the covers is harder.

Redux is more predictable.

Redux is (arguably) more testable.

MobX wins in terms of modularity.

Redux wins in terms of scalability and maintainability.

Redux has a lot more community.

She said you should start with setState. Only when you run into problems should you look for something more powerful in order to pull state out.

She felt that Redux was better for bigger teams. (I disagree.)

MobX allows you to use a single domain class to manage all your update logic.

MobX is good at reacting to state changes.

React is good at reacting to actions or events.

Whichever one you choose, it's not an end game. There's no vendor lock in. They're not framework specific.

She experienced moving a project from Redux to MobX.

Type Systems Will Make You a Better JavaScript Developer

Jared Forsyth from Khan Academy (and previously Facebook)

He has experienced both worlds.

JavaScript has a type system, but he says it doesn't give you nearly enough type errors. That inhibits debugging. You get weird type errors late.

Type errors: when you try to use a thing in a context where it doesn't belong.

Here are some of the ways to get more more type errors:

Linters can catch things that you're trying to use that are undeclared.

Custom runtime type checking (i.e. writing type checks manually in your code) is sometimes useful but frequently annoying. It's powerful, but it requires lots of extra boilerplate-y code, and it can only catch things at runtime.

React propTypes provide runtime type checking, but they're less annoying than doing it by hand.

Flow provides static type checking. In a lot of cases, Flow can infer types. It's much simpler than custom runtime checking.


  • Runs ahead of time
  • Doesn't require much boilerplate
  • Applies to everything (not just components)
  • Is great for documentation

He likes Flow. He said TypeScript is similar.

Adding Flow to code will help you find bugs.

Flow's editor integration is confusing.

Code that's too clever is hard to debug.

It's painful to deal with functions that are super flexible and treat the arguments differently based on how many arguments there are.

If it's hard to typecheck, it's probably hard to understand.

Flow helps with implicit invariants.

Sometimes, the best thing to do is to create a child component.

He talked about how to represent a state machine in a way that reduces complexity; try to structure the data to make it impossible to represent illegal states.

Flow has something like algebraic types.

If you're making a ton of things optional, you're probably trying to represent a state machine poorly.

Thinking about the types first sometimes makes things cleaner.

These are the times when you should think about types first:

  • State machines
  • Remote data types

These are the times when you should think about types later:

  • Simple data
  • Complex interactions

Lightning talks

Moving Fast with Nuclide and Flow

Andres Suarez

Nuclide is Facebook's IDE based on Atom.

It has good integration with Flow.

It has:

  • autocomplete
  • type hints
  • jump to definition
  • outline view
  • highlight references
  • push diagnostics


AWS Lambda + AWS Gateway + React = AWEsome

Sophia Shoemaker

With Lambda, you don't have to worry about a lot of the things you had to worry about with servers.

Lambda currently supports JavaScript, Python, and Java.

ServerLess goes hand-in-hand with create-react-app.

React to Code

Merrick Christensen

The idea is to look at changes to code over time and recommend further improvements based on recognized patterns.

He created react-sourcerer.

It responds to changes to your source code.

It works with ASTs.

state = parse(source)

Do something if the code is importing from lodash:

<Import from='lodash'>

The Road to Styled Components

Max Stoiber

It's another system to tie CSS to components.

CSS sucks.

It sucks for building component-based UIs.

"Colocate and isolate."

Remove the mapping between styles and components:

  • Write actual CSS
  • Have the power of JavaScript
  • Theming
  • React Native support

Building Applications for a Studio in the Cloud at Netflix

Feather Knee

She's working on an internal application built using React at Netflix. She wasn't able to show a screenshot.

Netflix was one of the earlier users of React.

Goal: pick the best content (e.g. movies, etc.), given the constraints.

They know what you will probably watch, based on statistical models. The models are often wrong, but they still manage to have good content.

They have to deal with picking content world wide.

She mentioned a lot of libraries they use.

React Native in the "Brown Field"

Leland Richardson from Airbnb

He talked about integrating React Native into large, existing native codebases.

React Native was launched 2 years ago.

Airbnb started playing around with it about a year ago.

460k LOC (native), 70k LOC (JavaScript)

Brownfield projects are the opposite of greenfield projects.

For React Native: don't reinvent everything in JavaScript. Take advantage of the underlying platform where it makes the most sense.

React Native is only 40% JavaScript.

Some of React Native is in C++.

Yoga is React Native's layout engine. It's written in C++.

React Native things usually have JavaScript APIs, but they are often implemented in native code.

You can write your own native libraries that are usable via JavaScript.

He talked about infrastructure code vs. product code.

There's still no clear answer for navigation in React Native.

  • NavigatorIOS
  • Navigator
  • NavigationExperimental

react-native-navigation is another such library.

Brownfield apps have unique constraints.

Airbnb had to build their own solution for navigation since some of their screens are native, and some of their screens are built using React Native.

One bridge, many React root views.

Two modes of navigating: pushing and presenting.

Render-time configuration: Navigator.config.

He talked about header components that show / hide when scrolling.

Shared element transitions: see a picture on the page, click on it, and the whole view zooms into it.

Leverage native APIs to create even better JavaScript APIs.

Important: They just open sourced their work:

Moving Beyond Animations to User Interactions at 60 FPS in React Native

Tal Kol from Wix

React Native really improves productivity.

Can React Native cross the last mile? The first 95% was really easy; it's about 4X more productive. The last 5% is much harder.

What makes great apps? Smooth transitions, animations, etc.

"animated" is part of the core, and it fixed the slow animations.

UIs are more persuasive when they matches the physical world.

He talked about dynamic user interactions that mimic reality. Swipe an email row, and it shows you actions you can do.

He talked about lots of features in apps where you swipe things out, and they have gravity, velocity, acceleration, etc.

react-native has a SwipeableRow.js library.

He talked about "traffic over the bridge" (between JavaScript and native code) where the animation is mostly implemented in JavaScript.

One way to improve performance is to reduce bridge traffic.

At Wix, only 10% of their engineers are native engineers.

Important: Declarative API are how we cross the last mile.

They're building a declarative API for user interactions.

He showed a bunch of nice looking animations for drawers, cards, swipeable rows, etc.

He talked about springs, friction, and snapping points.

He talked about implementing this kind of stuff using UIKit Dynamics which is a fully fledged physics engine in iOS. However, it's not available in Android.

He talked about reimplementing UIKit Dynamics, i.e. his own physics engine.

He started with Physics 101 on Wikipedia.

They're writing a declarative physics engine for views for React Native.

Search the app store for "React Native Interactions" to play with his examples.

Lightning talks

You Don't Need a Fancy Framework to Use GraphQL with React

Samer Buna

GraphQL is a replacement for REST for the sake of performance.

graphfront generates a GraphQL schema for your DB.

graphfront-ui generates an admin for your DB.

Cross-Platform Data Visualization with React and React Native

Peggy Rayzis

She's from Major League Soccer.

Victory: a modular charting library for React and React Native.

Using React for Anything but Websites

Ken Wheeler from Formidable

This was a talk about building "strange things" using React.

Spectacle is a JSX-based presentation library.

Victory is for building CLIs.

React-Game-Kit uses MatterJS.

He talked about react-music.

There are other custom renderers like react-hardware.

With Fiber, renderers are first class instead of total hacks.

React Everything, Render Everywhere

Dustan Kasten

In 2013, they introduced React and said HTML was only the beginning. Now we can even do VR with React.

There are lots of different rendering engines.

Fiber changes everything. There's a renderer API.

We own our output.

React motion for drag and drop.

Learn once render everywhere.

Create React Native App: 5 Minutes to "Hello, World!"

Adam Perry


You only need to have node installed.

It installs your app into the Expo app (???).

Testing works with Jest.

It doesn't support custom, native modules. But there are a bunch of libraries Expo gives you out of the box.

You can "eject" in order to generate the code and build under XCode and Android Studio.

Goodbye Flatland! An introduction to ReactVR and what it means for web developers

Michaela Lehr

VR concepts

She talked about stereoscopic images.

She talked about tracking sensors.

Here's what the stack looks like:

* Browser
* WebGL
* WebVR
* three.js
* ReactVR

There's a react-vr-cli tool. It can scaffold a project.

How do we present content to the user in this new environment where the user is "in" the environment?


There are components for all sorts of VR concepts.

In WebGL, you can think of X as pointing to the right, Y as pointing up, and Z points away from the user, with the user looking in the -Z direction. You can think of 1 unit = 1 meter.

There's a flexbox layout system.

There's an "Animated" API.

There's also sound; you can tie sound to a location.

UX Design and VR

There's a UX hierarchy:

  • Delight
  • Usefulness
  • Interpretability
  • Comfort (most important)

When sitting, you have a 70% cone of viewing. You can turn your head to see an additional 30% to each side (80% max).

Things should be further than 0.5m away and closer than 20m.

The devices have pretty low DPIs, so you should use fonts that are 20px or larger.

PPD = pixels per degree

Current devices have 10-12PPD. To get to the point where you can't see pixels anymore would require 60PPD.

More tips:

  • avoid eyestrain; use darker colors
  • avoid focusing on different depths
  • do not trigger phobias
  • use correct scales
  • do not move things too quickly towards the camera
  • do not attach things near the camera

Avoiding simulation sickness:

It happens when your senses are not in sync. For instance, when what you see doesn't match what you feel.

  • no acceleration
  • do not move the horizon or the camera
  • always keep a low latency and a high frame rate
  • avoid flicker and blur
  • add a stable point of focus
  • support short usage
  • abstract design is better than realistic

You are responsible for the well-being of your users. It's more serious in 3D.

Here are the slides.

Realtime React Apps with GraphQL

Robert Zhu from Facebook

Realtime apps are harder to build, but they give us a sense of connection.

You can no longer think of a client making a request and the server making a response. It's more of a conversation.

Doing realtime with React really comes down to having really good client-side state management and having a nice API.

You can use Relay, Redux, etc. for managing the client-side state. He's going to focus on the API.

Realtime APIs:

  • Pull
    • Polling
  • Push
    • Live queries
    • Subscriptions

Polling has a number of drawbacks, but it's simple, stateless, and intuitive.

With a live query, the server just tells you whenever there's an update to the data you're watching. However, this requires a reactive backend which is difficult to integrate and scale.

With subscriptions, you only get notified of state changes when the state change is something that's really important. Furthermore, you'll be notified about why you're getting this new state.

He talked about how much data the server should give to the client when a state change occurs.

The client should be able to specify the data that they need. That's what GraphQL is about. It's a query language for your API. "It's an elegant idea for a more civilized age." It's a "declarative data query language that lets clients specify exactly the data that they need."

"Wish driven design" = "when I'm building the client, I like to imagine the shape of the data that I wish I had."

"I'm extremely lazy, so the shape of the data should match exactly the shape of the data that I can pass into my React component as props."

GraphQL query:

 query {
     emails {


    "emails": [{
        "from": "",
        "subject": "hey",
        "isRead": false,


subscription {
    importantEmail {

On the client, he's using React and Relay.

GraphiQL is the GraphQL IDE. It lets you explore a GraphQL schema.

When you run a subscription, it doesn't respond immediately. It waits for events to come in.

The third type in GraphQL is mutation.

There's something else that's like Relay called Apollo.

In his example code, he's using await.

He's using web sockets to talk to the server.

Facebook has been operating GraphQL subscriptions at scale for over two years.

It powers live likes, live comments, and streaming reactions on live videos.

GraphQL is evolving incrementally.

Once things are more standardized, he expects the community to build a variety of clients and servers across transports and backends.


Jest Snapshots and Beyond

Rogelio Guzman

He doesn't like tests as much as he likes the idea of testing.

They had a problem where it took a lot of effort for fewer tests, instead of less effort for more tests.

Moving to Jest was easy. Tests were 6X faster. Runs were instant.

He mentioned snapshot tests.

yarn add -D jest
yarn jest -- --watch
it('Adds up two numbers', () => {

Sample code:

There's a problem with running code, and then just copying the results into the test.

Jest has an approach called snapshot testing.

expect(sum(1, 2)).toMatchSnapshot();

It saves the output of the function to a .snap file.

If the output of the function suddenly changes, the test will fail.

Jest takes care of managing the snapshots for you. It adapts to changes. It's easy to maintain. It's much easier than doing this process by hand.

If the snapshot doesn't match the output of the test, you can recognize that it's a bug, or you can have it update the snapshot automatically.

Snapshot serializers let you customize what the snapshots look like:

    test: …,
    print: …

You can use snapshots to test the output of components.

const component = renderer.create(
    <MovieList query="f" />

Jest has a serializer for the output of components.

There's a enzyme-to-json/serializer library. It works with shallow, mount, etc.

You can use expect(...).toMatchSnapshot() in a loop. Adding more snapshots lets you test more things without increasing the complexity of the tests.

jest-movie: think of a movie where each snapshot is a frame. I think he's still working on this library.

Jest isn't just a testing framework; it's a testing platform.

Jest: jest-snapshot, pretty-format, jest-validate, etc.

Prettier is using jest-validate to validate CLI invocations.

A Beginner's Guide to Code Splitting Your React App

Neehar Venugopal

Facebook has been doing code splitting since 2008. They're working with the Chrome team.

Code splitting is really easy.

70% of our traffic comes from mobile in India. We have to be mobile first.

The nice thing about mobile is that we have evergreen browsers. (I think he's overlooking Facebook webviews.)

Think about long term caching. Split out the third-party libraries into their own bundle. Put a hash in the filename. Tell it to cache the file forever in the CDN and in the browser.

Next, split the code into per-functional-area bundles. Send only the minimum amount of JavaScript required.

ES6 provides built in async loading of modules.

Before, we used to use require.ensure.

Now, we use import(...) to load code asynchronously. It's stage 3. It's in Webpack 2. It returns a promise. It accepts dynamic module names. Webpack implements this by adding an asynchronous script tag to the head.

Components can be: functions, classes, etc., but they can't be promises. Fiber may support this.

Loading components vs. loading data: they can be treated the same. Hence, you can have a component that uses componentWillMount to fetch code. Async modules are promises. Treat them as any other type of data that you fetch dynamically.

Route-level splitting is almost always the best place to start.

Beware of code duplication across multiple bundles.

In React Router v3, there's a getComponent attribute so that you can asynchronously load your code.

Split within top-level routes. Each async route is a distinct output file.

They've been experimenting with the idea of responsive components. Load the mobile JavaScript code first, and upgrade to desktop if necessary. He's thinking of mobile-first JavaScript.

Conditional imports are easy.

In practice, server side rendering gets tricky when you're loading things dynamically on the client.

Always profile on real devices.

Avoid network waterfalls. Try to load all the things you need in parallel rather than serially.

Use link preload and prefetch when appropriate.

Remember, import() is always async and that promises always resolve asynchronously.

"If you can write a component that makes an API call, you can write a component that is lazily loaded."

Web-Like Development and Release Agility for React Native

Parashuram N from Microsoft

React Native: The JavaScript VM sends actions to the native UI and receives events from the native UI.

The packager is something that runs on your local machine, bundles your code, and sends it to the JavaScript VM.

You could run the packager in the cloud, and then update the device in real time. This is how code push works.

People do use code push in production. It doesn't violate iOS's terms of service since they have a specific exception for JavaScript.

Mobile Center:

It's like a DevOps pipeline. You can upload your certificates. It will take care of CI for your mobile app. It has a pretty UI.

They have a feature where you can test your app on real world devices. All the devices will work together in sync even though you're using manual testing. Pretty neat!

mobile-center-crashes and mobile-center-analytics.

He's using VS Code.

If you shake your phone really hard, you can get your phone to debug JavaScript remotely in Chrome.

You can tell React Native to run the code in Node, and then debug it with VS Code. You can even replace Node with Node Chakra.

Chakra has a Step Back feature where you can rewind the entire JavaScript context of the app.

He said, use TypeScript or Flow to avoid type errors.

You can use code-push to quickly push updates to your phone.

The Step Back feature is like time traveling debugging, but encompasses even more. You can even replay events like you can in Redux.

You can push a fix to your code even without waiting for Apple to approve your new version.

This guy is really talented :)

They're working on code signing.


  • Has excellent Flow and TypeScript support
  • Has an extension named "ReactNative tools" that's pretty helpful
  • Can deploy directly to Exponent
  • Lets you debug Exponent apps
  • Has Node-Chakra code and time travel debugging

He said that time travel debugging is always an experiment.

His slides:

His demos were amazing.

React-Storybook: Design, Develop, Document and Debug your React UI components

Marie-Laure Thuret

A UI component relies on several states.

How do you make sure your UI components are well documented, tested, etc. in a standalone manner?

React Story Book: an isolated environment to quickly design and build your UI components.

Develop, design, document, debug, discuss.

It's a standalone UI to work on your component. Neat!

(She's using VS Code.)

It lets you build documentation in a nice way.

It creates UI to play with your component.

Working on your component in an isolated way helps you think of the API first.

It's a nice thing to link to in your docs.

It can help with testing too.

"Storyshots" is a feature where you can test your markup using snapshot testing.

The Specs add-on lets you write explicit tests near your component.

You can link to a storybook in your GitHub PR.

  • Hot reloading
  • Isolated environment
  • Iterate quickly
  • Create a style guide
  • Live docs
  • Add specs through tests
  • Expose props
  • Entry points for debugging
  • Isolate bugs
  • Share stories

It has an add-on API.

Extensible React

Cameron Westland from Autodesk

Autocad is extensible.

How do you make your app more extensible?

  • 1st party - you working on your own product
  • 2nd party - customers adding to your product
  • 3rd party - an ecosystem of addons to a platform

He's going to just focus on the architecture of your thing that needs to be extensible.

"Lifting state up" works only if you own a common ancestor.

A portal is when you have a component nested in your code, but it actually creates the DOM markup at the end of the body. React modal does this.

He talked about using slots and fills as a way of providing extensibility. There's a react-slot-fill library. You can expose a global extension point, and you can render children into the slot.

He's using VS Code.

Everyone loves extensible apps.

Lightning talks

Building React Communities Outside of Your Circle

Troy Connor

He said he was a diversity candidate last year. This year, he's a speaker.

Mentor. Empower others. Promote diversity.

A Prettier Printer

James Long

Our current tooling is not enough. ESLint is not a formatter.

"We are the knights of nit." I.e. we send each other a lot of "nit:" comments in our PRs.

We need to stop dealing with nits manually.

Hence, he came up with Prettier. Its an opinionated JavaScript formatter.

A bunch of big projects such as Babel are either using it already or plan on using it.

It'll restructure your code depending on your max line length.

It understands Flow types, JSX, etc.


  • Consistency
  • Teachability
  • Freedom (not to worry about reformatting code)

He showed an example where leaving out a semicolon resulted in a bug. They're thinking of adding a feature to support people who prefer not to use semicolons, but they don't have that feature yet. Brendan Eich apparently likes people to use semicolons.

Neat: During the talk, the React guys let him merge a pull request to integrate Prettier :)

How to React in the Slow Lane

Nicole Chung

She talked about progressive web apps. You'll get more users.

She talked about code splitting. She talked about link rel preload.

She talked about caching, and then service workers.

She talked about the Lighthouse plugin--very useful.

She said your page should be responsive in 5 seconds on a 3G connection.

The Great Convergence with React

Aditya Punjani

They've used both progressive web apps and React Native.

When you add a progressive web app (PWA) to your homescreen, an actual APK gets created and installed on your phone.

React PWA best practices:

  • Aggressive caching
  • Extensive code splitting
  • Bypass React for animations

React Native best practices:

  • Pre-parse JavaScript
  • Recycler List View
  • Incremental JavaScript download

React is a platform. The same React engineers can work on both web and native.

Web benefits:

  • Instant load
  • Always up to date
  • No storage requirements

Native benefits:

  • Smooth and fluid
  • Service and hardware APIs
  • Discovery, reviews, and ratings

"Always bet on React" :)

Learn Once, Route Anywhere

Michael Jackson and Ryan Florence from React Training!

They built React Router.

60% of people using ReactDOM also use React Router.

64 people contributed to React Router v4. It finally shipped last week.

V4 is almost entirely "just components".

The API is so small, you can memorize it. He went through it.

They built a library called "history" for managing the browser history.

Native apps do have URLs, and you can link to any document in your app. You have a bit more control since the user doesn't have a URL bar.

They support React Native and deep linking.

They can handle the Android back button just fine.

The web is actually the most hostile environment.

One of them was using MacVim.

They have nice animations during navigation.

They did a fun thing where Michael kept saying they were going to work on something for their next talk and Ryan would say that he already built it and whip out the demo. This was particularly cool when they had a demo for React VR since they must have thrown it together using code from the earlier React VR talk.

Taming the Meta-Language

Cheng Lou

Brendan Eich is apparently in the crowd.

Reason is a new programming language from Facebook. It has a friendly syntax and toolchain. It's built on top of OCaml. It was built by the creator of React.

There's so much stuff aside from the language itself that you need to build in order to make a language successful. He calls this stuff "meta code".

How do we express higher level concepts without the need of a library?

Facebook was using OCaml already for Hack and Flow. React was originally prototyped in SML by Jordan Walke. People weren't ready for an ML then. Hence, he rewrote it in JavaScript.

There are ReactJS bindings for Reason. You can interoperate with your existing code.

propTypes become just part of the language using normal types.

The syntax of Reason is meant to look very familiar to JavaScript developers.

Reason has an option type: option (array string)

It supports JSX if you want.

It has label arguments setCoordinates x::10 y::200;

You can swap the argument order since they're named.

Theme of the talk: drag things down into the language.

Classes -> modules. It's a language level concept. It's a big concept.

Modules map to files in OCaml. Modules are first class, which means they can be passed to functions.

He talked about throwing away code--you're throwing away bad code, but you're also throwing away important lessons that were learned.

Less is more.

The problem with JavaScript is that just because you know JavaScript doesn't mean you'll be immediately productive in a radically different JavaScript community.

Instead of using cloneElement, you can just use currying.

You no longer need setState most of the time. Instead, you return a Some {...state, newText: "Hello" }.

There's a syntax formatter. In fact, Prettier was inspired by Reason's formatter.

There's a linter, but no one uses it.

It has per-library, pluggable error reporting.

Types kill a category of tests, but not all tests. Once you have types, you can test more important things.

Reason puts comments into the AST. Comments are even type checked.

Macros could potentially also work on comments.

Documentation becomes easier with types.

They have a sensible way of dealing with deprecation messages.

He used phrases such as "taking the metalanguage". By this, he meant bringing things that weren't in the metalanguage (proptypes, comments, etc.) and putting them into the language.

Some things don't get built into the language; some should get baked into the build tool. is 25% converted to Reason.

It's not just an academic oddity. You can actually use it in production.

Reason compiles to JavaScript because there's an OCaml to JavaScript compiler.

OCaml itself also compiles to native, of course.

Inspirations: Elm (inspired by Haskell), F# (also inspired by OCaml), Clojure

Informal Panel Q&A

They're not live streaming this.

  • Ben: works on React (including Fiber) at Facebook
  • Sebastian works on React at Facebook
  • Spencer works on React Native at Facebook
  • Leland works at Airbnb on their Native Infra team (using React Native)
  • Lin works at Mozilla on emerging tech (WebAssembly, Rust, Servo)

Fiber is really a new foundation for a lot of work to come in the future.

Mobile simulators aren't nearly as good as using the real device. This is even more important for React Native compared to normal web development.

With React Native, there are some cases where that last 5% is really hard to make it as nice as developing a native app.

componentWillReceiveProps should only be used to call setState.

Dominic (???) said that React might get better than Inferno in terms of speed.

Preact and Inferno have been inspiring. Preact's number one goal is size. Inferno's number one goal is performance. The Facebook team has put serious effort into bundle size as well as performance. They're playing and learning.

Stateful, functional components are an idea that they've thought about. They're not really pure. The problem is that if they do provide such an API, they can't guarantee certain invariants that they need to ensure.

Closing Remarks

"Optimism is the catalyst for human progress."

Being nice is more important than the tech.


Tom said…
Wow, JJ, this is an amazing amount of words--most of which, I have no clue what they mean. Aside from that, you impress the heck out of me with your thoroughness and insight on this subject. God has blessed you beyond your years.
jjinux said…
Thanks, Tom ;)
Mark Erikson said…
I was also at ReactConf, and you did a great job capturing the key info from each talk. Still worth watching each of the talks for those who haven't seen them yet, but that's an excellent writeup. Kudos!
jjinux said…
Thanks, Mark!

Popular posts from this blog

Ubuntu 20.04 on a 2015 15" MacBook Pro

I decided to give Ubuntu 20.04 a try on my 2015 15" MacBook Pro. I didn't actually install it; I just live booted from a USB thumb drive which was enough to try out everything I wanted. In summary, it's not perfect, and issues with my camera would prevent me from switching, but given the right hardware, I think it's a really viable option. The first thing I wanted to try was what would happen if I plugged in a non-HiDPI screen given that my laptop has a HiDPI screen. Without sub-pixel scaling, whatever scale rate I picked for one screen would apply to the other. However, once I turned on sub-pixel scaling, I was able to pick different scale rates for the internal and external displays. That looked ok. I tried plugging in and unplugging multiple times, and it didn't crash. I doubt it'd work with my Thunderbolt display at work, but it worked fine for my HDMI displays at home. I even plugged it into my TV, and it stuck to the 100% scaling I picked for the othe

ERNOS: Erlang Networked Operating System

I've been reading Dreaming in Code lately, and I really like it. If you're not a dreamer, you may safely skip the rest of this post ;) In Chapter 10, "Engineers and Artists", Alan Kay, John Backus, and Jaron Lanier really got me thinking. I've also been thinking a lot about Minix 3 , Erlang , and the original Lisp machine . The ideas are beginning to synthesize into something cohesive--more than just the sum of their parts. Now, I'm sure that many of these ideas have already been envisioned within , LLVM , Microsoft's Singularity project, or in some other place that I haven't managed to discover or fully read, but I'm going to blog them anyway. Rather than wax philosophical, let me just dump out some ideas: Start with Minix 3. It's a new microkernel, and it's meant for real use, unlike the original Minix. "This new OS is extremely small, with the part that runs in kernel mode under 4000 lines of executable code.&quo

Haskell or Erlang?

I've coded in both Erlang and Haskell. Erlang is practical, efficient, and useful. It's got a wonderful niche in the distributed world, and it has some real success stories such as CouchDB and Haskell is elegant and beautiful. It's been successful in various programming language competitions. I have some experience in both, but I'm thinking it's time to really commit to learning one of them on a professional level. They both have good books out now, and it's probably time I read one of those books cover to cover. My question is which? Back in 2000, Perl had established a real niche for systems administration, CGI, and text processing. The syntax wasn't exactly beautiful (unless you're into that sort of thing), but it was popular and mature. Python hadn't really become popular, nor did it really have a strong niche (at least as far as I could see). I went with Python because of its elegance, but since then, I've coded both p