React Native Internals - Speaker Deck

Slide 1

Slide 1 text

REACT NATIVE INTERNALS Kansas City Developer Conference 2018

Slide 2

Slide 2 text

Hi.  I’m Simon I run a dev team building cool stuff with React and React Native. @sstur_ Previously @ Facebook in California  Currently CTO at KodeFox, Inc. simon@kodefox.com

Slide 3

Slide 3 text

We’ll talk about a few things today. What is React Native What lies ahead? How Does it work? (internals)

Slide 4

Slide 4 text

React Native is a set of tools to write native apps in JavaScript, based on the ideas of React. WHAT IS REACT NATIVE?

Slide 5

Slide 5 text

• Command-line tool • npm library • Bundler • Set of native modules and UI primitives • Layout engine • API between native and JS • Set of debugging tools • … and more. WHAT IS REACT NATIVE?

Slide 6

Slide 6 text

• Not the same as React on web, although it shares some code. • No WebView or HTML or CSS or DOM. • Does not use

or or any of the web primitives • Does not “re-create” the platform’s native components • Not really a “hybrid” framework in the typical sense (like Ionic) • Does not “compile” your JavaScript to native code. WHAT REACT NATIVE IS NOT

Slide 7

Slide 7 text

• Allows you to build your application 100% in JavaScript (or TypeScript) • Build with native components rendered by native code. • You can apply much of your existing experience from Web  (box model, flex layout)

Slide 8

Slide 8 text

React Native was created at Facebook with a few design goals in mind. WHY WAS REACT NATIVE  CREATED?

Slide 9

Slide 9 text

• Solve the challenges of building two separate native apps. • Single language and set of tooling across iOS and Android • Developer experience of web with the power of native mobile. • Leverage the core concepts developers love about React. DESIGN GOALS “Learn once, write anywhere”

Slide 10

Slide 10 text

We want the power and performance of  native apps with the awesome  development experience of the web.

Slide 11

Slide 11 text

• Write code, save, reload  … like a refreshing a web page. • Instant feedback, helpful errors. • Simple, powerful layout system using Flexbox • Scale easily to large teams WEB

Slide 12

Slide 12 text

• Smooth animations • Complex, natural-feeling gestures • Fast and responsive • Excellent end-user experience • Deep hardware integration NATIVE MOBILE

Slide 13

Slide 13 text

LET’S LOOK AT SOME CODE

Slide 14

Slide 14 text

No content

Slide 15

Slide 15 text

IF YOU’VE DONE SOME REACT ON THE WEB, THEN YOU ALREADY KNOW REACT NATIVE.

Slide 16

Slide 16 text

…but JavaScript?!

Slide 17

Slide 17 text

• Modern JavaScript is surprisingly fast and well optimized. • The JavaScript ecosystem is mature with plenty of great tooling. • React is well known for solving perf issues on the web. HTML/CSS is slow; The DOM is slow. Animations can be slow if they’re driven from JS

Slide 18

Slide 18 text

You can achieve performance that is indistinguishable to the user from a native app written in Swift or Java.

Slide 19

Slide 19 text

…but how?!

Slide 20

Slide 20 text

REACT NATIVE  INTERNALS

Slide 21

Slide 21 text

HOW IT WORKS Bridge { } Native  Thread(s) JavaScript  Thread

Slide 22

Slide 22 text

JavaScript  Thread • All the code you write essentially runs here. • Non-blocking, single-threaded. • Intentionally Isolated; no shared memory. • Can only communicate with the native side by message passing.

Slide 23

Slide 23 text

JavaScript  Thread Most of the JS constructs you know and love: • fetch() • Promises; async/await • JSON • require() and import

Slide 24

Slide 24 text

{ } Native  Thread(s)

Slide 25

Slide 25 text

{ } Native  Thread(s) Use analogy of server-rendered HTML • Instantiating, styling and positioning native elements. • Converting Flexbox layout to pixel- based layout (Yoga). • Interfacing with the hardware (GPS, Network, camera) • Notifying the JS side about events (such as device rotation or touch)

Slide 26

Slide 26 text

{ } Native  Thread(s) • Mostly this is framework code. • You do not normally write  native code when building Apps with React Native. • Unless you’re a library author.

Slide 27

Slide 27 text

THE BRIDGE { } Native JavaScript

Slide 28

Slide 28 text

• Handles message passing between JavaScript and Native • Each message is completely serializable and the format looks like JSON. • Message passing is asynchronous. • Each message is essentially a command (method call) The  Bridge

Slide 29

Slide 29 text

No content

Slide 30

Slide 30 text

• All your business logic runs on the JS side. • All code that interfaces with hardware runs on the Native side. • Example messages from JS -> Native:  - Placement of an element on screen  - Sending a network request • Example messages from Native -> JS:  - Notification of user input (touch / scroll)  - Network response

Slide 31

Slide 31 text

Asynchronous, Batched, Serializable This builds upon and formalizes some of the principles used by React on the web.

Slide 32

Slide 32 text

This provides such a clearly defined abstraction it's almost like two network devices communicating over HTTP or WebSocket. In fact, you can sub out the bridge for an actual WEBSOCKET for debugging.

Slide 33

Slide 33 text

But… The bridge is slow (relatively) The message queue can be a  bottleneck.

Slide 34

Slide 34 text

Remember, every message has to be serialized and gets put in the queue to be processed in batches. THE MESSAGE  QUEUE

Slide 35

Slide 35 text

This causes many operations to be async. Like when JS queries simple hardware info. THE MESSAGE  QUEUE

Slide 36

Slide 36 text

No content

Slide 37

Slide 37 text

Native JavaScript 1. Send message to  request network info. 2. Query the hardware  and compose a  response message. 3. Receive response  and pass to callback.

Slide 38

Slide 38 text

For most tasks, this is no problem.  The React design pattern is great for batching updates.

Slide 39

Slide 39 text

Doing any of this on the JS thread: • Animation: updating layout every frame. • Re-rendering an element onScroll. • Gestures: swiping or pinch-to- zoom. • Basically everything you love about native interactions. THINGS THAT WILL  CONGEST  THE BRIDGE

Slide 40

Slide 40 text

SO HOW THEN  CAN REACT NATIVE BE FAST?

Slide 41

Slide 41 text

Just don’t do animation and gesture handling on the JavaScript thread.

Slide 42

Slide 42 text

IN REACT NATIVE, WE USE A DECLARATIVE APPROACH  FOR ANIMATION AND GESTURES.

Slide 43

Slide 43 text

We write code that describes what we want, not how it should be done. DECLARATIVE /dih-klar-uh-tiv/ adjective

Slide 44

Slide 44 text

EXAMPLE Imperative Declarative I want a blue square on the screen. (I don’t care what’s currently on the screen) • Get the shape that’s on the screen. • If it’s not a square, call setShape(‘square’) • If it’s not blue, call setColor(‘blue’)

Slide 45

Slide 45 text

Describe the animation, but let the native side calculate the intermediate frames. DECLARATIVE  ANIMATIONS

Slide 46

Slide 46 text

No content

Slide 47

Slide 47 text

ONE PASS ACROSS THE BRIDGE  TO KICK-OFF THE ENTIRE ANIMATION. A single return message to notify the JS  when the animation is done.

Slide 48

Slide 48 text

In this context, a gesture is an animation that is attached to an ongoing user interaction (swipe, scroll). GESTURE VS  ANIMATION

Slide 49

Slide 49 text

The libraries for declarative animations and gestures are getting better all the time.    New Hotness: “reanimated” BETTER ANIMATION  AND GESTURES

Slide 50

Slide 50 text

Credit: @HenryKirkness https://github.com/kirkness/interactions 60FPS  GESTURES &  ANIMATIONS

Slide 51

Slide 51 text

Native JavaScript 1. Send the description  of the animation. 2. Compute and render  all the frames. 3. Get notification that  animation is finished.

Slide 52

Slide 52 text

THIS TALK IS NOT REALLY ABOUT ANIMATION But it’s an important part of high-performance mobile.

Slide 53

Slide 53 text

TITANIUM SPONSORS Platinum Sponsors Gold Sponsors K C D C 2 0 1 8

Slide 54

Slide 54 text

WHAT OTHER ADVANTAGES do we get?

Slide 55

Slide 55 text

• Excellent perf even when another thread is busy • Better use of multi-cores. • Clean abstractions and separation of concerns. Since all of our business logic (our application code) runs on a different thread,

Slide 56

Slide 56 text

Since the JavaScript is interpreted, we get some other cool stuff. • Almost instantaneous code reload. • Over the air updates (yes, even on iOS) • Sandbox/playground to easily experiment with React Native JAVASCRIPT

Slide 57

Slide 57 text

In fact, with Expo Snack, you can actually… • Go to https://snack.expo.io • Write some code • Instantly run it on your device. • … with hot-reloading.

Slide 58

Slide 58 text

No content

Slide 59

Slide 59 text

THIS IS POSSIBLE BECAUSE Your application code is JavaScript  which is interpreted.

Slide 60

Slide 60 text

Specifically, React Native uses JavaScriptCore (from Safari) which runs on iOS without JIT.

Slide 61

Slide 61 text

LET’S TALK ABOUT LAYOUT

Slide 62

Slide 62 text

HISTORICALLY, THIS HAS BEEN HARD TO DO

Slide 63

Slide 63 text

FLEXBOX HAS MADE LAYOUT TRIVIAL Mostly.

Slide 64

Slide 64 text

Yoga is a library from Facebook, originally made for React Native. • Built mostly in C++ • Platform independent • Takes in flex properties (flexDirection, alignItems, etc) • Outputs [top, left, width, height] • That’s all it does. YOGA yogalayout.com

Slide 65

Slide 65 text

Online Playground for Layout

Slide 66

Slide 66 text

Flex Layout Coordinates

Slide 67

Slide 67 text

No content

Slide 68

Slide 68 text

No content

Slide 69

Slide 69 text

LAYOUT GETS ITS OWN THREAD This helps a lot with smooth UI.  Almost zero frame drops for native driven animations.

Slide 70

Slide 70 text

In fact, there are several threads on the Native side. • Main Thread: in charge of startup; launches other threads, including the JS thread • UI/Layout Thread • One thread for each native module:  network, localStorage, custom modules

Slide 71

Slide 71 text

SO TO SUMMARIZE

Slide 72

Slide 72 text

Your entire JS application, you can think of as a system that takes events as inputs and produces commands as outputs. THE JAVASCRIPT  SIDE

Slide 73

Slide 73 text

You can think of the Native side like the web browser or the render engine. THE NATIVE SIDE

Slide 74

Slide 74 text

An asynchronous, batched message bus between the two systems. THE BRIDGE

Slide 75

Slide 75 text

WHERE DO WE GO FROM HERE Have we solved cross-platform mobile?

Slide 76

Slide 76 text

Slide 77

Slide 77 text

BUT REACT NATIVE IS HERE TO STAY FOR A WHILE.

Slide 78

Slide 78 text

• Libraries will always be written in low-level, native code. • Application code is moving more towards higher-level, cross- platform solutions,  such as React Native or Flutter. • More frameworks are building on the ideas of React THE TREND, AS  I SEE IT

Slide 79

Slide 79 text

• The next generation frameworks that replace React Native will probably not use JavaScript • There’s nothing about the React Native paradigm that requires JavaScript • Better, more strongly typed languages are coming about, such as ReasonML and Kotlin • Declarative is the right way to do UI and will have a huge influence on future frameworks.