16 April 2016

React Amsterdam 2016: The React Native Playground

Speaker: @jsierles

Talks about: React Native Playground

Important to get stuff out there (easily).

Inspired by @vjeux who wished there was a JSFiddle like experience for React Native.

appetize.io provided a free emulators for React Native.

Future: Test on real devices, not in the browser.

app.reploy.io let your users test your app, make screenshots and provide feedback, all in the browser.

Future supporter and tool to use: reindex.io

React Amsterdam 2016: Solving a Tooling Problem for React Native

Speakers: @kureevalexey and @grabbou

Tooling for Dependencies:
Today npm (Node Package Manager)

Problem using npm for React Native

React Native modules are more complex than JavaScript modules, because they contains more:
  • JS
  • Platform code
  • Assets

What's next?

  • Linking core libraries
  • One tool to rule them all (right now: npm + React Native + rnpm). React Native team and speakers are working together on this.

Mentioned in demos:

React Amsterdam 2016: State Management Is Easy

Speaker: @mweststrate

Personal opinion: I disagree with what the speaker said during the presentation. However, I do have to dive into this, because it might be a communication issue.
Managing state is hard because of human limitations. It doesn't become easy by reducing the amount of code. The amount of state and state changes remain the same. Less code and databinding has been tried (and failed). Problem space needs to be broken down in manageable pieces. It's like juggling with 20 balls, no matter what we do to make it easier, it is still impossible.

Challenge: The DOM is hard
Solution: React

Challenge: State Management is hard
Solution: Redux (?) - MobX


State Management is hard because:

  • Static State is not hard
  • Changing State is hard
State should be minimally defined:
  • No Caching
  • No Data Duplication
  • No Cascading State Changes
  • Don't worry about how the app should react to state!
MobX = fast

React Amsterdam 2016: Introducing and Implementing React at Coolblue

Speaker: Paul van Dam

Why React?

JavaScript fatigue

Many different tools and components needed to build a decent app.

Tackle the fatigue:
  • Fail often (don't be afraid to fail)
  • Learn from mistakes
  • Expand


Continues integration:
  • ESLint
  • Unit test
  • Pull requests
  • ...
  • Build
  • Deploy

Semantic Vesioning:
  • Problem: ˆ3.0.2 (different versions in use by developers)
  • Fix: 3.0.5 (everyone uses the same version)
  • But... It assumes developers follow rules
node modules can be platform dependent

Mentions: npm shrinkwrap


React Amsterdam 2016: Testing React Applications

Speaker: @jack_franklin

Uses to test: Tape


Testing Interactions:
Test doubles, libraries:
Alternative to verbose React's Test Utils:

Run tests:

Slides of this and other presentations by the speaker can be found here.

React Amsterdam 2016: React WebGL in Liberty Global

Speaker: @pixelscommander

New setup box every 2 years. Abstract the rendering to protect against platform changes.

WebGL is used becauce:

React Amsterdam 2016: React Component Libraries

Speakers: @operatino (Liberty Global)

Ziggo's Horizon Go app is written in React with component reuse in mind.

Talk is too short to mention all, therefor he refers to other talks he has given (slides).


  • Choose tech base
  • Choose tools
  • Build

React Amsterdam 2016: React for Game Development

Speaker: @frostney_

Why React for games, there are already tons of platforms?
First rule of game jams: Use the tools you're most familiar with.

Demonstrates: phaser.io

Type of games:

  • Event-based
  • Frame-based
Techniques of games:
  • Game Loop:
  • Dirty Rectangle Checking
  • Components & Entities. In React everything is a component.
  • Scene Graph (entities in a tree structure), comes with React for free.
React is usable, not perfect for game development.

React Native? Native components are not important for game development.

React Amsterdam 2016: Building (Reactive GraphQL Apps With) Apollo

Speaker: @martijnwalraven (Meteor)

Tech talk about: Apollo and GraphQL

See also: Building Apollo Medium Blog

Long term project, so not finished. Talk is about the vision.


Meteor, consists of:

  • View layer (React can replace this)
  • Data stack (Minimongo / MongoDB)
  • Build tool
REST vs Meteor
  • Imperative data fetches vs declaritive data requirements
  • Lists of endpoints vs semantic data with identity
  • Independent request vs stateful client-side caching


Apollo can be seen as the next version of the Meteor Data Stack, but... Apollo is independent!

Apollo will connect to:
React, Angular, Swift, Andoird, Java, Python, Scala, Go, Ruby

Why you want Apollo?
Need to do Application Data Management

Decouple client from services

To decouple client from services, there is a need for a query language and GraphQL fills this gap.

Lifecycle of a query:
  1. UI passes data requirements to client
  2. queries diffed against existing stored data
  3. minimized query sent to server
  4. data aggregated from backend services
  5. result returned to client
  6. client updates store
  7. result is delivered to the UI
Work with the rest of the GraphQL community, not in isolation.

To do: Building tools to improve the GraphQL developer experience

Not fond of Relay, Apollo tools focus on debugging, transparency and simplicity.

First alpha of Apollo Client will probably  be released this week.

React Amsterdam 2016: React Native Internals

Speaker: @tadeuzagallo

React Native

  • No WebView
  • No HTML
  • No CSS
  • Only JS

React Native App

Has a Bridge with the following threads:

  • Main
  • JavaScript
  • ShadowQueue (where layout happens)
  • Native Modules threads:
    • Network
    • LocalStorage
    • YourCustomModule

What happens when you run a simple app? (for graph, see sheets)

  1. Load the JavaScript Bundle
  2. Load the Native Modules
  3. Start the JavaScript VM
  4. Load the JSON configuration
  5. Execute the Application's JavaScript bundle
  6. Abstract JavaScript Execution
  7. Create Shadow Views
  8. (Compute) Layout (in background thread)
  9. Create Native Views
  10. Render to Screen
Now the user starts interaction, what happens the first time? (for graph, see sheets)
  1. User interaction
  2. UIKit
  3. Native Module
  4. Abstract JavaScript execution
  5. JavaScript call to Native
  6. Bridge
  7. Native module
Now the user starts the same interaction, what happens? (for graph, see sheets)

    1. User interaction
    2. Native module

    Question: Why iOS first and Android second

    Started with hackaton and iOS. Android team is larger now and is catching up.

    Question: Will you support other platforms?

    The team is to small to do so. The recent announcement that React Native will get support for Windows Universal Applications is actually a Microsoft only effort because Microsoft like React Native to support their platform.

    React Amsterdam 2016: Mastering Server-rendered Apps

    Speaker: @svenardocom

    Book written by de speaker: ReactJS Blueprints

    Server-rendered Apps were previously known as isomorphic. Nowadays universal is a more common name, but still has a different meaning to different people. Proposal: shared.

    Why server rendering?

    • Page loading is too slow (less sales)
    • Google Cache / Internet Archive
    • User cannot run JS

    When JavaScript is slow?

    • User uses old hardware
    • User has a slow connection (mobile)

    Demonstrates: reactjsblueprints-shared.herokuapp.com

    Solution: ReactDOMServer.renderToString

    Demonstrates use of ReactDOMServer.renderToString.

    • Fast
    • Reuse of frontend code
    • Works when no JS on the frontend
    • Complex server files
    • Need to rely on a fetch method before render
    • Relative slow due to lack of optimisations (like caching)

    Improved solution: react-dom-stream

    Demonstrates use of react-dom-stream.

    Out of the box solution: fluxible.io

    Mentions: fluxible.io

    React Amsterdam 2016: JavaScript Style Sheets

    Speaker: @oleg008

    Why / Problems

    React is about components
    CSS is for documents


    • Global namespace
    • Implicit dependencies
    • Dead code
    • Minification
    • Sharing constants (between CSS and JS)
    • Non-deterministic resolution (CSS specificity concept)
    • Isolation (very high specificity)
    • Complex selectors
    • Redundancy
    Mentions: @vjeux's talk React: CSS in JS (slides)


    3 options:
    • Pure Inline (misses some features & performance problems)
    • Mixed Mode (complicated code)
    • Pure Inline Style Sheets
    Pure Inline Style Sheets can be done with JSS library (written by the speaker).

    JSS library

    Virtual CSS Tree -> Process -> Render

    • Lazy compilation
    • Ref counting
    Offers things not available with Inline Styles:
    • Media Queries
    • Keyframes Animation
    • Font Faces
    • Pseudo Selectors
    • Fallbacks
    • Rules Caching
    • Rules Sharing
    Other benefits compared to Inline Styles:
    • Class Names are fast
    • Smaller payload
    • Tools Agnostic
    • Extensible (mentions: JSS-isolate)
    Problems left:
    • Feels overengineered to some
    • Wrong language for some
    • No standard DSL
    • Blocks initial rendering


    Not just for big projects, but also if maintainability counts.

    React Amsterdam 2016: Building loveable UI's

    Speaker: @healves82 (DADI+)

    React is a library for building ambitious user interfaces.

    Developer experience improves with:

    Design components not pages:
    • Atomic design
    • Content & display patterns
    • Functional CSS
    Naming is hard, therefore use:
    • Content-based names
    • Visual names
    • Functional names
    Two types of components:
    • Container: Talks to stores
    • Presentational: Render UI (no state, often functional component)
    Other considerations:
    • Classes or function?
    • CSS or inline styles
    • Use animation to improve experience
    • Animation
    • Gestures
    • Layout system

    React Amsterdam 2016: Migrating Safely to React

    Speaker: @jamischarles (PayPal)
    Download: Slides

    From complex to simple

    Pain PayPal had:
    • Too many abstraction layers
    • Low confidence
    • Difficult state bugs
    Original focus: Ship, not maintainability.

    Simple -> predictable -> Reliably

    View layer

    Obvious solution: PayPal choose to use React.

    Lessons learned with React:
    • React simplifies the view (fewer files)
    • Quick win
    • Push it to production to test it in the wild

    Routing layer

    Originally: Backbone routing was used.
    Solution: Use React Router and bridge with Backbone router for the time being.

    Rewrite took 3 weeks.

    Data layer

    Originally: Backbone models & collections which become complex easily.
    Solution: Redux. You can go back and forth in time,  reducing the debugging time from hours to minutes.

    What about old data?
    Rebuilding means lots of A/B testing and QA.


    Use as much vanilla JavaScript as possible. Backbone was chosen 2 years ago and now they already moved on. So try not to rely too much on React and Redux, we will have the same problems in 2 years time.