React.js Conf 2016 Quick Summaries — Day 1, Part 1
I was lucky enough to attend React.js Conf 2016, and as presentation happened I jotted a few notes about each talk. These aren’t complete summaries and there will be errors in the notes, but hopefully they’ll point you in the right direction when deciding which talks to watch.
You can see the complete schedule here.
Thanks to inFlow Inventory for sponsoring my attendance.
Nick Schrock (Facebook)
- Breadth, depth, and fervor of adoption of React makes it unique
- Breadth: React Developer Tools Chrome Plugin has 250,000 installs in just a few years
- Depth: Large media companies, sports companies embraced React, all in under 3 years
- Fervor: ReactConf feels like a quasi-religous event.
When I speak externally the one thing most people want to talk to me about is react — Mike Schroepfer
- Later year React Native was announced and changed React from just web to be used in many other platforms
- But a common reaction is: I’ve heard this story of cross platform before. Just because it didn’t work before, doesn’t mean it won’t be implemented better this time.
- When do ideas work? Taste (the way an app should be structured), Timing (the world is ready for this), and Technology (the right technology is in place to execute the vision)
- Mobile devices are ready for a framework like this
- React makes React Native a different cross platform technology than others because of the way that it structures apps (immutable data, virtual DOM, etc). These concepts are universal so much so that ComponentKit ObjectiveC UI library steels actively from React.
- React has values, it has taste, about the way software should be structured, and that’s its competitive advantage
- JS is a competitive advantage.
- PCs aren’t going away. Desktop is still important important. The web and mobile web are important.
- JS isn’t going anywhere. Facebook is investing in JS
- Multicore is becoming universal. React Native architecture is uniquely suited for multicore: implicit parallelism, declaritve APIs, immutablity is inherintingly threadsafe
- NOT Write once, run anywhere; proprietary platforms will always differentiate and compete. Learn once, run anywhere.
- Take advantage of those native capabilities, share when possible, go native when necessary
- APIs, tools and languages, code… share a lot of code, not all of it
- Get native code to use proprietary capabilities: for compute intensive tasks, to preserve existing investments in built native code if it’s already working.
- You don’t need to re-write code that’s already there, so React Native has a lower barrier to entry.
- Example: Facebook Ads manager is available in iOS, Android. These feel native, share 85–90% code, but built by a single team
- React native adoption within Facebook is accelerating. Facebook is investing into React Native, want React to be a self sustaining community but someone has to lead the way, so put it in the most used app in the world
- Facebook uses React Native in production apps: Groups app, Ads app, friends day video component
- Facebook Events dashboard is being moved to React Native.
- Mobile revolutions has been a huge step back for developers are users demand native, fast experiences of their everyday devices that live in their pocket.
- The web was a revolution in how software developers and organizations operate: better ecosystem, instant distribution, open standards, fast iteration, unified product teams
- Moving from web to native code as being like ripped back in time to platform aware teams, compiled languages, etc.
- React Native can transform organizations
- Improving React Native also improves React.js
- We’re on the cusp of redefining what it means to construct mobile applications.
Ben Alpert (Facebook)
In the last few years, React has exploded in popularity, now supporting hundreds of thousands of developers on the web. React also lies at the heart of React Native, which has made it easier than ever to build native mobile apps.
On the React team, we’re continually making performance and stability improvements so that React can be a strong foundation. But in our role of helping developers build high-quality products quickly, what new opportunities for React do we see in the future? In this talk, hear about the latest challenges we’re facing at Facebook, how React might be able to help solve them in the future, and how we think about developing React.
- Things to work on in React. No code for these have been written so up for the community to build.
UX: user experience
- important about where to reason about where you are in the app, helpful for spatial reasoning.
- What’s the best way to do animations in React? react transition group, react motion, Animated is baked into React Native, views can be declarative based on state, the key is now that animated is its own state.
- often overlooked when building apps, especially on mobile web
- it’s the one difference between web apps and nativeapps that make them feel web-y
- pan, pinch, tap, double tap, press and hold… can’t build all these gestures with browser events
- Goal: simple component API written in JSthat abstracts gesture system away from Android, iOS and hopefully add this to the web
3. Performance: Making List Fast
- Almost all mobile apps are made of lists
- Windowing: only render what’s on screen, something that’s not super easy in react right now
- Rendering in chunks: break up rendering to avoid jank, depending on complexity of item dozens of views might come on screen to render, in that rendering time the scroll would be janky. render in junks across multiple frames
- Layout: React does a good job preventing layout reflows: component that wants to render something differently depending on the space available, re-render by checking size, then render the new component
- Make layout information available within the render of the component: will avoid unnecesary reflows, makes windowing simpler, don’t render things that are offscreen, skip creation of layout only views: divs that are only there to group other elements together
- 60% of facebook.com divs weren’t doing anything except layout
- build new layout primitives
- layout in CSS is hard, flexbox helps, but doesn’t do aspect ratios, grid layout
- If dimensions are in React directly could build on top of it without waiting for browser support. build your own abstractions for layout
DX: Developer experience
- focus on developer experience means can devs can build apps faster
- faster iterations leads to higher quality apps
- New Project Experience
- It’s a big pain right now to use the latest tools and setup has to happen before any code: node, npm, gulp, webpack, babel are all useful for building apps
- The dream is to create a single JS file, specify platform and run
- Goal: quickly prototype with one file, then slowly grow the app
2. Dev Tools
- React devtools inspector for Chrome/Firefox to inspect tree of elements
- React hot loader, React transform, changes trigger browser update for instant viewing
- IDE support (nuclide, deco), built for React Native, see information about components inline with the code, change styles and see changes
3. Data Management
- Most people start with React setState, but it keeps the state encapsulated in your component, can’t share with other component
- Flux/Redux is used to pull data into stores, accessible wherever, but server communication is up to you, a lot more setup before you can do anything
- Relay, makes it easy to get data from server to your components, colocated queries in your component, but Relay won’t work if you don’t have GraphQL servers, Relay doesn’t help you if you have a lot client side data that doesn’t have relations on the server
- Goal: combine best of all three, structure apps where it’s really easy to reuse any part: Data and UI layer can be swapped out, changed, moved, independently
- React already used in production, so give it appropriate vesion
- new minor version can be released more often
- React is a growing community: 300 contributors commited to React in 2015, 600 React Native contributors
Rich Text Editing with React
Isaac Salier-Hellendag (Facebook)
The below technology has been open-sourced by Facebook! http://facebook.github.io/draft-js/
Plain text is boring. At Facebook, we want to give our users the ability to add mentions, emoticons, hashtags, styles, and embedded media within the content they share. The result is that nearly every input on Facebook requires rich text features.
As UI engineers, we want to provide our product teams with the tools to implement and expand upon these features without pushing them into the contentEditable pit of despair.
This talk will dive into the details of how we used React, ImmutableJS, and yes, contentEditable, to create an editor framework that enables engineers to build and customize rich text composition experiences across Facebook.
- Anatomy of a Facebook input, consists of text, mentions, hashtags, all highlighted, all different data
- Pre-2014 used <textarea> and <div>
- Problems with <textarea> Managing structured input is hard, undo/redo, copy/paste is broken for mentions, limited the rich text capabilities (bold, headers, embedded media), required a lot of DOM measurement hacks to keep text area growing
- Goal: Improve flexibility of text inputs across Facebook
- Options: textarea with highlighter <div> elements (buggy, not full featured enough); draw all contents manually (must draw and position fake cursor); contentEditable (DOM is state; no way to separate them with this)
ContentEditable, the good parts
- still works in browsers
- native cursor that the browser handles
- native events
- international text support
- rich text support
- automatic autogrowing
- accessible by default to screen readers
- Goal 2: integrate seamlessly into React Apps: state and render should be different, but ContentEditable ties the two together
- Create a React controlled ContentEditable
- Strict control of contents using React
- strict control of cursor using native selection API
- create declaritive, understandable API
- support internalize, copy/paste, spellcheck, support arbirtray rich text so can build whatever needed for the future
- How? Controlled contents: keydown happens, prevent default so browser doesn’t intervene, model splits and re-renders, use native selection API to set cursor
- Modeling rich text: what does state look like?
- It’s a snapshot of the complete state of the text editor, where’s the cursor, undo/redo state
- Editor state: record object represents all data about the block, it’s immutable, it has attributes about the text
- Cursor snapshot: given a coordinate, put the cursor down. Use keys to represent records and set coordinates to represent the cursor state. When the cursor moves new state is created to track where to put the cursor
- Undo/Redo: when typing could record operations that occurred, but don’t want to undo each letter at a time; create heuristics based on browser behaviour to keep only a handful of snapshots, immutable states
- initial state operates on simple text for mentions
- split around “@mention” from simple text
- insert structured text
- apply mention to text range
- add meta-data
- Express a complex edit operation as a composition of simple operations.
A Cartoon Guide to the Wilds of Data Handling
Lin Clark (Mozilla)
I’m going to walk you through the wilds of data handling in react. I call it “the wilds” because when you first look at the landscape, it seems to be overflowing with an untamed profusion of different options. The boundaries between these options aren’t clear, and it’s hard to see why you’d want to pick any one in particular.
When you look closer, you’ll see that it’s actually easier to navigate than you might think. You just need a good guide.
- Landscape of data handling can look untamed, but there are 3 distinct ways of doing things in React
- http://code-cartoons.com project started to understand Flux, and Flux shows up in all other technologies
- Flux and React was developed to solve bugs like the ‘notification bug’ in Facebook where notification numbers would be cleared and then come back
- Models and views were linked and changes affect views and models in unpredictable way
- Flux solved this with unidirectional data flow
- Flux is a group of characters working together as a team
- The Action Creator is telegraph operator who knows how to tell others the type of action that happened
- The Dispatcher is a switchboard operator who knows how to send the change out to the systems that care
- The Store is an over controlling beaurocrat who knows how to update the data but only in the way that it knows and accepts
- The Container View is a middle manager that can talk to the store and get data changes, gives that information to the presentational view
- The Presentational View is the presenter of data and knows how to show the data to the user
Flux was created to end the cycle of brokenness; and all rejoiced; and created a hundred different implementations of it
- Keep a snapshot of state of changes, but never change each state. States are immutable, they never change but copies are changed
- View layer binding is like an IT department that hooks up the state to the views
- Where’s the cloud? How do you sync data with a server?
- Flux doesn’t have one set place to do this
- Redux does have one place, that’s the middleware, but you have to find the tools and wire it all up (caching, query optimization, taking care of network errors)
- Relay keeps track of which bits of an entire graph that your components need
- Compared to endpoints that gives you data, if new componenets need new data, data needs to be added to the endpoint coupling them
- Relay bundles needed data by components and queries an endpoint only for that data; then caches the data
- Data can be deferred, only query for important data first, then query for secondary
- Data can be cached and only changed data can be fetched
- Data can optimistically update local cache and then push change, and when that comes down can handle errors or merge in new data
- Flux creates unidirectional data flow. Redux splits apart state from the what updates it. Relay connects graph in the cloud to the graph on your client