🇩🇪 iJS Munich 2023

Slide 1

Slide 1 text

Hello, Munich! 👋 🇩🇪 DEEP DIVING ON CONCURRENT REACT • THE 24TH OF OCTOBER, 2023.

Slide 2

Slide 2 text

DEEP DIVING ON CONCURRENT REACT MATHEUS ALBUQUERQUE • @ythecombinator

Slide 3

Slide 3 text

↑ ALL THE LINKS! 🧑🏫 TECHLABS 🐦 @ythecombinator 👨💻 MEDALLIA ⚡ PERF GDE SPEED AT SCALE: OPTIMIZING THE LARGEST CX PLATFORM OUT THERE /

Slide 4

Slide 4 text

#question 🤔 Who here works with front-end? And React?

Slide 5

Slide 5 text

#heads-up 🥱 60 minutes is a lot of time, I know…

Slide 6

Slide 6 text

No content

Slide 7

Slide 7 text

Preamble DEEP DIVING ON CONCURRENT REACT /

Slide 8

Slide 8 text

DEEP DIVING ON CONCURRENT REACT /

Slide 9

Slide 9 text

WE TALKED ABOUT… ↝ FIBERS ↝ COROUTINES ↝ GENERATORS ↝ ALGEBRAIC EFFECTS

Slide 10

Slide 10 text

WE TALKED ABOUT… ↝ FIBERS ↝ COROUTINES ↝ GENERATORS ↝ ALGEBRAIC EFFECTS I WANTED TO DISCUSS MORE… ↝ VIRTUAL DOM ↝ CONCURRENCY/PARALLELISM ↝ CONCURRENT REACT ↝ MEASUREMENT

Slide 11

Slide 11 text

DATA-DRIVEN UI LIBRARIES DOM RECONCILIATION E.G. ANGULAR, POLYMER, LIT-HTML VIRTUAL DOM E.G. REACT, VUE, INFERNO REACTIVE E.G. KNOCKOUT, SVELTE, SOLID

Slide 12

Slide 12 text

DOM RECONCILIATION E.G. ANGULAR, POLYMER, LIT-HTML VIRTUAL DOM E.G. REACT, VUE, INFERNO REACTIVE E.G. KNOCKOUT, SVELTE, SOLID DATA-DRIVEN UI LIBRARIES

Slide 13

Slide 13 text

DEEP DIVING ON CONCURRENT REACT /

Slide 14

Slide 14 text

#quote 💬 “[…] With React you can build applications without even thinking about performance and the default state is fast.” — Rethinking Best Practices by Pete Hunt, 2013

Slide 15

Slide 15 text

VIRTUAL DOM ↝ GENERATE A VIRTUAL TREE AND THEN DIFF AGAINST THE PREVIOUS ITERATION ↝ PATCH THE DOM UPDATES ↝ USE IMMUTABILITY AND REFERENTIAL EQUALITY TO OPTIMIZE THE PROCESS WHICH RESULTS IN SIGNIFICANT CLONING AND MEMORY ALLOCATION

Slide 16

Slide 16 text

PERF MITIGATORS ↝ shouldComponentUpdate, React.PureComponent ↝ React.memo ↝ useMemo, useCallback ↝ useTransition, useDeferredValue, React.Suspense & others

Slide 17

Slide 17 text

#protip 💡 React doesn’t have any understanding of the values running through your app. It’s not reactive.

Slide 18

Slide 18 text

VIRTUAL DOM

Slide 19

Slide 19 text

VIRTUAL DOM

Slide 20

Slide 20 text

VIRTUAL DOM ↝ IT HAS BEEN OPTIMIZED WELL ENOUGH IN MOST SCENARIOS ↝ WE DON’T COMPLAIN ABOUT PERF IN INFERNO OR BUNDLE SIZE IN PREACT ↝ THERE ARE LIBRARIES THAT CAN PRODUCE EQUIVALENT/ SMALLER BUNDLES (E.G. HyperApp)

Slide 21

Slide 21 text

VIRTUAL DOM ↝ IT'S JUST ONE OF THE APPROACHES WE HAVE AND IT'S NEVER A TRUE/FALSE QUESTION ↝ UNDERSTANDING ITS KEY TAKEAWAYS HELPS US UNDERSTAND WHERE CONCURRENT REACT FITS

Slide 22

Slide 22 text

#question 🤔 Why do we even bother discussing Concurrent React?

Slide 23

Slide 23 text

PERFOMANCE

Slide 24

Slide 24 text

PERFOMANCE PERCEIVED LOAD SPEED HOW QUICKLY A PAGE CAN LOAD AND RENDER ALL OF ITS VISUAL ELEMENTS TO THE SCREEN SMOOTHNESS DO TRANSITIONS & ANIMATIONS RENDER AT A CONSISTENT FRAME RATE AND FLOW FLUIDLY? LOAD RESPONSIVENESS HOW QUICKLY A PAGE CAN LOAD/RUN ANY REQUIRED JS IN ORDER FOR COMPONENTS TO RESPOND TO USER INTERACTION RUNTIME RESPONSIVENESS AFTER THE PAGE LOAD, HOW QUICKLY CAN THE PAGE RESPOND TO USER INTERACTION?

Slide 25

Slide 25 text

PERFOMANCE PERCEIVED LOAD SPEED HOW QUICKLY A PAGE CAN LOAD AND RENDER ALL OF ITS VISUAL ELEMENTS TO THE SCREEN LOAD RESPONSIVENESS HOW QUICKLY A PAGE CAN LOAD/RUN ANY REQUIRED JS IN ORDER FOR COMPONENTS TO RESPOND TO USER INTERACTION RUNTIME RESPONSIVENESS AFTER THE PAGE LOAD, HOW QUICKLY CAN THE PAGE RESPOND TO USER INTERACTION? SMOOTHNESS DO TRANSITIONS & ANIMATIONS RENDER AT A CONSISTENT FRAME RATE AND FLOW FLUIDLY?

Slide 26

Slide 26 text

LONG TASKS

Slide 27

Slide 27 text

LONG TASKS

Slide 28

Slide 28 text

LONG TASKS

Slide 29

Slide 29 text

LONG TASKS

Slide 30

Slide 30 text

#research 📚 Phone users experience slow First Input Delay on 7x more websites. — Web Almanac By HTTP Archive, 2021

Slide 31

Slide 31 text

FIRST INPUT DELAY DESKTOP PHONE 0 25 50 75 100 SLOW ( > = 250MS) AVERAGE FAST (<50 MS)

Slide 32

Slide 32 text

BUSINESS OUTCOMES ↝ LONG TASKS DELAYED TTI ↝ AS FIRST-PAGE LONG TASK TIME INCREASED, OVERALL CONVERSION RATES DECREASED ↝ MOBILE HAD UP TO ˜12X LONGER LONG TASKS ↝ OLDER DEVICES COULD BE SPENDING HALF OF THEIR LOAD-TIME ON LONG TASKS — AKAMAI AND CHROME RESEARCH, 2017

Slide 33

Slide 33 text

BUSINESS OUTCOMES — AKAMAI AND CHROME RESEARCH, 2017

Slide 34

Slide 34 text

#answer 💡 That’s why we do bother discussing Concurrent React!

Slide 35

Slide 35 text

#question 🤔 If you were to summarize Concurrent React in one word/expression, what’d be your pick?

Slide 36

Slide 36 text

#question 🤔 If you were to summarize Concurrent React in one word/expression, what’d be your pick? e.g. fibers ↝ units of work Concurrent React ↝ ???

Slide 37

Slide 37 text

If you were to summarize Concurrent React in one word/expression, what’d be your pick? DEEP DIVING ON CONCURRENT REACT /

Slide 38

Slide 38 text

The Main Thread DEEP DIVING ON CONCURRENT REACT /

Slide 39

Slide 39 text

TASKS A UNIT OF WORK THAT THE BROWSER DOES TO RENDER A FRAME JAVASCRIPT STYLES LAYOUT PAINT COMPOSITE

Slide 40

Slide 40 text

TASKS JAVASCRIPT STYLES LAYOUT PAINT COMPOSITE

Slide 41

Slide 41 text

LONG TASKS ↝ IF A TASK TAKES MORE THAN 50 MS, USER INPUT FEELS DELAYED ↝ BASED ON THE USER-CENTRIC PERFORMANCE MODEL CALLED RAIL ↝ THEY TAKE TOO LONG AND BLOCK OTHER TASKS

Slide 42

Slide 42 text

#QUESTION 🤔 How to avoid blocking the main thread?

Slide 43

Slide 43 text

TASK RUNNING STRATEGIES PARALLELISM ↝ MULTIPLE THREADS = MULTIPLE TASKS AT THE SAME TIME ON SEPARATE CPU CORES CONCURRENCY ↝ SINGLE THREAD + QUICKLY SWITCHING BETWEEN TASKS SCHEDULING ↝ CONCURRENCY + TASK PRIORITIZATION

Slide 44

Slide 44 text

TASK RUNNING STRATEGIES A B C D

Slide 45

Slide 45 text

TASK RUNNING STRATEGIES PARALLELISM CONCURRENCY SCHEDULING

Slide 46

Slide 46 text

TASK RUNNING STRATEGIES PARALLELISM CONCURRENCY SCHEDULING

Slide 47

Slide 47 text

WORKERS ↝ VERY DIFFERENT FROM THE THREADS IN C++, JAVA, ETC. ↝ NO ACCESS TO ANY VARIABLES/CODE FROM THE PAGE THAT CREATED THEM OR VICE VERSA ↝ DATA EXCHANGE IS THROUGH MESSAGE-PASSING

Slide 48

Slide 48 text

WORKERS ↝ NO ACCESS TO THE DOM, MAKING UI UPDATES FROM A WORKER BARELY IMPOSSIBLE ↝ APPS THAT INTEND TO USE THEM HAVE TO ADAPT THEIR ARCHITECTURE TO ACCOMMODATE THESE REQUIREMENTS ↝ TWO MODELS: ACTORS & SHARED MEMORY 🤯

Slide 49

Slide 49 text

WORKERS: ACTORS ↝ EACH ACTOR MAY OR MAY NOT RUN ON A SEPARATE THREAD ↝ EACH ACTOR FULLY OWNS THE DATA IT IS OPERATING ON ↝ ACTORS CAN ONLY SEND/REACT TO MESSAGES ↝ MAIN THREAD = ACTOR THAT OWNS THE DOM/UI 🤯

Slide 50

Slide 50 text

WORKERS: ACTORS ↝ EVERY MESSAGE WE SEND NEEDS TO BE COPIED ↝ BALANCE: MOVING CODE TO A WORKER VS COMMUNICATION OVERHEAD/WORKER BEING BUSY ↝ postMessage IS A FIRE-AND-FORGET MESSAGING MECHANISM WITH NO BUILT-IN UNDERSTANDING OF REQUEST AND RESPONSE 🤯

Slide 51

Slide 51 text

WORKERS: SHARED MEMORY ↝ ONE DEDICATED TYPE: SharedArrayBuffer ↝ A LINEAR CHUNK OF MEMORY THAT CAN BE MANIPULATED USING TypedArrays OR DataViews ↝ IF SENT VIA postMessage, THE OTHER END GETS A HANDLE TO THE EXACT SAME MEMORY CHUNK 🤯

Slide 52

Slide 52 text

WORKERS: SHARED MEMORY ↝ MOST OF THE APIS ARE BUILT NO CONCURRENT ACCESS TO OBJECTS IN MIND ↝ YOU BUILD YOUR OWN MUTEXES AND OTHER CONCURRENT DATA STRUCTURES ↝ NO DIRECT WAY OF WORKING ON FAMILIAR OBJECTS/ ARRAYS; JUST A SERIES OF BYTES 🤯

Slide 53

Slide 53 text

WORKERS: WEB ASSEMBLY ↝ WORKERS + SharedArrayBuffers TO SUPPORT THE THREADING MODEL OF C++ AND OTHERS ↝ BEST EXPERIENCE FOR SHARED-MEMORY MODEL ↝ FASTER THAN JS WHEN YOU STAY WITHIN WASM, BUT THE MORE YOU HAVE TO CROSS OVER TO JS APIS THE SLOWER IT IS

Slide 54

Slide 54 text

WORKERS: WEB ASSEMBLY ↝ JAVASCRIPT IS OFTEN FASTER AT DOING DOM RENDERING ↝ HIGH-LEVEL LIBRARIES CAN BE MORE PERFORMANT THAN LOW-LEVEL WASM IMPLEMENTATIONS ↝ DOESN’T OFFER LOT OF THE BENEFITS (AND COMFORT) OF JAVASCRIPT

Slide 55

Slide 55 text

↝ Atomics ↝ BuffferBackedObject ↝ Comlink ↝ WorkerDOM ↝ Partytown ↝ AND MUCH MORE!

Slide 56

Slide 56 text

WORKERS ↝ GOOD FOR DATA PROCESSING AND CRUNCHING NUMBERS ↝ HARD TO USE FOR UI-RELATED STUFF ↝ HARDER THAN ADJUSTING IT FOR A SCHEDULER

Slide 57

Slide 57 text

TASK RUNNING STRATEGIES PARALLELISM CONCURRENCY SCHEDULING

Slide 58

Slide 58 text

If you were to summarize Concurrent React in one word/expression, what’d be your pick? DEEP DIVING ON CONCURRENT REACT /

Slide 59

Slide 59 text

Scheduling in React DEEP DIVING ON CONCURRENT REACT /

Slide 60

Slide 60 text

SCHEDULING IN REACT HEURISTICS COOPERATIVE MULTITASKING WITH A SINGLE INTERRUPTIBLE RENDERING THREAD PRIORITY LEVELS REGISTER CALLBACKS WITH DIFFERENT PRIORITY LEVELS IN THE BROWSER RENDER LANES ABSTRACTIONS AROUND A BITMASK; BRING GRANULARITY, AVOID OVERHEAD & ALLOW BATCHING

Slide 61

Slide 61 text

SCHEDULING IN REACT function resourcefulOperation(value: number) { let newValue = String(value); for (let i = 0; i < 1000000; i++) { newValue = `${value} + ${i} = ${value + i}`; } return newValue; } function ResourcefulComponent(props: { value: number }) { const { value } = props; const result = resourcefulOperation(value); return

{result}

; }

Slide 62

Slide 62 text

DEEP DIVING ON CONCURRENT REACT /

Slide 63

Slide 63 text

#question 🤔 How could we improve that?

Slide 64

Slide 64 text

DEEP DIVING ON CONCURRENT REACT /

Slide 65

Slide 65 text

REDUX-SAGA

Slide 66

Slide 66 text

{result}

; }

Slide 67

Slide 67 text

function* resourcefulOperation(value: number) { let newValue = String(value); while (true) { yield; for (let i = 0; i < 1000000; i++) { newValue = `${value} + ${i} = ${value + i}`; } return newValue; } } const initialValue = 0; const scheduler = new Scheduler(resourcefulOperation, initialValue); function ResourcefulComponent(props: { value: number }) { const { value } = props; const result = scheduler.performUnitOfWork(value); return

{result}

; }

Slide 68

Slide 68 text

{result}

; } PROMOTED TO A GENERATOR YIELDING EXECUTION DOING CONCURRENT TASKS

Slide 69

Slide 69 text

DEEP DIVING ON CONCURRENT REACT /

Slide 70

Slide 70 text

enum SchedulerState { IDLE = "IDLE", PENDING = "PENDING", DONE = "DONE", } class Scheduler { state: SchedulerState; result: T; worker: (data: T) = > Generator; iterator: Generator; constructor(worker: (data: T) = > Generator, initialResult: T) { this.state = SchedulerState.IDLE; this.worker = worker; this.result = initialResult; } performUnitOfWork(data: T) { switch (this.state) { case "IDLE": this.state = SchedulerState.PENDING; this.iterator = this.worker(data); throw Promise.resolve(); case "PENDING": const { value, done } = this.iterator.next(); if (done) { this.result = value; this.state = SchedulerState.DONE; return value; } throw Promise.resolve(); case "DONE": this.state = SchedulerState.IDLE; return this.result; } } }

Slide 71

Slide 71 text

performUnitOfWork(data: T) { switch (this.state) { case "IDLE": this.state = SchedulerState.PENDING; this.iterator = this.worker(data); throw Promise.resolve(); case "PENDING": const { value, done } = this.iterator.next(); if (done) { this.result = value; this.state = SchedulerState.DONE; return value; } throw Promise.resolve(); case "DONE": this.state = SchedulerState.IDLE; return this.result; } }

Slide 72

Slide 72 text

DID WE JUST useTransition’ED? 🤔

Slide 73

Slide 73 text

{result}

; }

Slide 74

Slide 74 text

{result}

; }

Slide 75

Slide 75 text

YES, WE DID 🤓 WITH OUR OWN SCHEDULER

Slide 76

Slide 76 text

HEURISTICS ↝ A COOPERATIVE MULTITASKING MODEL ↝ A SINGLE INTERRUPTIBLE RENDERING THREAD ↝ RENDERING CAN BE INTERLEAVED WITH OTHER MAIN THREAD TASKS AND OTHER REACT RENDERS ↝ AN UPDATE CAN HAPPEN IN THE BACKGROUND WITHOUT BLOCKING THE RESPONSE TO NEW INPUT

Slide 77

Slide 77 text

HEURISTICS ↓ ORIGINAL RENDER TASK USER INPUT → ↑ HIGHER PRIORITY RENDER TASK ↓ RESUME ORIGINAL RENDER TASK

Slide 78

Slide 78 text

HEURISTICS

Slide 79

Slide 79 text

HEURISTICS

Slide 80

Slide 80 text

HEURISTICS ↝ IT YIELDS EXECUTION IS BACK TO THE MAIN THREAD EVERY 5MS ↝ IT'S SMALLER THAN A SINGLE FRAME EVEN ON 120FPS, SO IT WON'T BLOCK ANIMATIONS ↝ IN PRACTICE, RENDERING IS INTERRUPTIBLE

Slide 81

Slide 81 text

BRANCHING WORKFLOW — EVERYTHING YOU NEED TO KNOW ABOUT CONCURRENT REACT (WITH A LITTLE BIT OF SUSPENSE) • HENRIQUE YUJI

Slide 82

Slide 82 text

BRANCHING WORKFLOW — EVERYTHING YOU NEED TO KNOW ABOUT CONCURRENT REACT (WITH A LITTLE BIT OF SUSPENSE) • HENRIQUE YUJI

Slide 83

Slide 83 text

BRANCHING WORKFLOW — EVERYTHING YOU NEED TO KNOW ABOUT CONCURRENT REACT (WITH A LITTLE BIT OF SUSPENSE) • HENRIQUE YUJI

Slide 84

Slide 84 text

PRIORITY LEVELS

Slide 85

Slide 85 text

PRIORITY LEVELS

Slide 86

Slide 86 text

PRIORITY LEVELS PRIORITY TIMEOUT WHEN I m m ediate SYNCHRONOUSLY TASKS THAT NEED TO RUN SYNCHRONOUSLY UserBlocking 250MS RESULTS OF A USER INTERACTION (E.G. A BUTTON CLICK) Normal 5S UPDATES THAT DON’T HAVE TO FEEL INSTANTANEOUS Low 10S TASKS THAT CAN BE DEFERRED BUT MUST STILL COMPLETE EVENTUALLY (E.G. AN ANALYTICS NOTIFICATION) Idle NO TIMEOUT TASKS THAT DO NOT HAVE TO RUN AT ALL (E.G. HIDDEN OFFSCREEN CONTENT)

Slide 87

Slide 87 text

RENDER LANES ↝ ONE LANE = ONE BIT IN A BITMASK ↝ ONE UPDATE IN REACT = ONE LANE ↝ ONE RENDER IN REACT = ONE OR MORE LANES ↝ UPDATES IN THE SAME LANE RENDER IN THE SAME BATCH. ↝ DIFFERENT LANES, SEPARATE BATCHES. 🤯

Slide 88

Slide 88 text

RENDER LANES ↝ 31 LEVELS OF GRANULARITY (= ONE BITMASK) ↝ ALLOWS TO CHOOSE WHETHER TO RENDER MULTIPLE TRANSITIONS IN A SINGLE BATCH OR RENDER THEM INDEPENDENTLY ↝ REDUCES OVERHEAD OF MULTIPLE LAYOUT PASSES, STYLE RECALCULATIONS, AND MULTIPLE PAINTS 🤯

Slide 89

Slide 89 text

No content

Slide 90

Slide 90 text

No content

Slide 91

Slide 91 text

#question 🤔 How do we benefit from these in our everyday projects?

Slide 92

Slide 92 text

Scheduling in React (For the Rest of Us) DEEP DIVING ON CONCURRENT REACT /

Slide 93

Slide 93 text

SCHEDULING (FOR THE REST OF US) HANDLING LOTS OF DATA WITH THE useTransition HOOK TACKLING WASTED RENDERS WITH THE useSyncExternalStore HOOK HYDRATION IMPROVEMENTS WITH SELECTIVE HYDRATION & CONCURRENT REACT PROFILER ENHANCEMENTS INSPECT TRANSITIONS, GET WARNS, AND MUCH MORE!

Slide 94

Slide 94 text

HANDLING LARGE SETS OF DATA DEEP DIVING ON CONCURRENT REACT #1 of 4

Slide 95

Slide 95 text

HANDLING LARGE SETS OF DATA 😔 NON-PRACTICAL… ↝ FINDING PRIMES ↝ CRACKING PASSWORDS ↝ SIERPINSKI TRIANGLE 😊 PRACTICAL… ↝ RENDERING MANY DATA-POINTS ↝ RENDERING ON A ↝ PROCESSING DATA

Slide 96

Slide 96 text

Slide 97

Slide 97 text

DAILY VISITORS: BEFORE

Slide 98

Slide 98 text

DAILY VISITORS: BEFORE const DailyVisitors = () = > { const [data, setData] = useState(initialData); useEffect(() = > { setData(initialData); }, []); const onChange = (newData) = > { setData(newData); }; return ( ); }; export default DailyVisitors;

Slide 99

Slide 99 text

DAILY VISITORS: BEFORE const DailyVisitors = () = > { const [data, setData] = useState(initialData); const [, startTransition] = useTransition(); useEffect(() = > { setData(initialData); }, []); const onChange = (newData) = > { startTransition(() = > { setData(newData); }); }; return ( ); }; export default DailyVisitors;

Slide 100

Slide 100 text

DAILY VISITORS: AFTER

Slide 101

Slide 101 text

↝ ˜100K DATA POINTS PLOTTED ↝ SUPPORT FOR SEARCHING AND FILTERING ↝ USED WORKERS + REDUX-SAGA UTILITIES + DEBOUNCING ↝ COULD'VE USED TRANSITIONS LOCATION DATA #1 of 2

Slide 102

Slide 102 text

↝ THOUSANDS OF REAL-TIME PLAYERS MESSAGING ↝ SUPPORT FOR SEARCHING AND FILTERING ↝ USED VIRTUALIZATION AND MEMOIZATION ↝ COULD'VE USED TRANSITIONS GAME ADMIN PANEL #2 of 2

Slide 103

Slide 103 text

DEEP DIVING ON CONCURRENT REACT /

Slide 104

Slide 104 text

REAL WORLD EXAMPLE

Slide 105

Slide 105 text

FAST COMPUTER: NO TRANSITIONS

Slide 106

Slide 106 text

FAST COMPUTER: WITH TRANSITIONS

Slide 107

Slide 107 text

SLOW COMPUTER: NO TRANSITIONS

Slide 108

Slide 108 text

SLOW COMPUTER: WITH TRANSITIONS

Slide 109

Slide 109 text

DEEP DIVING ON CONCURRENT REACT #2 of 4 TACKLING WASTED RENDERS

Slide 110

Slide 110 text

useSyncExternalStore function useSyncExternalStore( subscribe: (onStoreChange: () = > void) = > () = > void, getSnapshot: () = > Snapshot, getServerSnapshot?: () = > Snapshot ): Snapshot;

Slide 111

Slide 111 text

DEEP DIVING ON CONCURRENT REACT /

Slide 112

Slide 112 text

DEEP DIVING ON CONCURRENT REACT /

Slide 113

Slide 113 text

useSyncExternalStore

Slide 114

Slide 114 text

useSyncExternalStore

Slide 115

Slide 115 text

#question 🤔 How do we benefit from these in our everyday projects?

Slide 116

Slide 116 text

No content

Slide 117

Slide 117 text

useLocation function Pathname() { const { pathname } = useLocation(); return ; } function Hash() { const { hash } = useLocation(); return ; }

Slide 118

Slide 118 text

useLocation function Pathname() { const { pathname } = useLocation(); return ; } function Hash() { const { hash } = useLocation(); return ; } OVER-RETURNING HOOK

Slide 119

Slide 119 text

SPEAKERS LIST: BEFORE

Slide 120

Slide 120 text

useHistorySelector function useHistorySelector(selector) { const history = useHistory(); return useSyncExternalStore(history.listen, () = > selector(history)); } function Pathname() { const pathname = useHistorySelector((history) = > history.location.pathname); return ; } function Hash() { const hash = useHistorySelector((history) = > history.location.hash); return ; }

Slide 121

Slide 121 text

Slide 122

Slide 122 text

SPEAKERS LIST: AFTER

Slide 123

Slide 123 text

DEEP DIVING ON CONCURRENT REACT #3 of 4 HYDRATION IMPROVEMENTS

Slide 124

Slide 124 text

HYDRATION: BEFORE FETCHING DATA (SERVER) RENDERING HTML (SERVER) LOADING CODE (CLIENT) HYDRATING TIME TO FIRST BYTE FIRST CONTENTFUL PAINT TIME TO INTERACTIVE 124

Slide 125

Slide 125 text

↝ HYDRATION COULD ONLY BEGIN AFTER THE ENTIRE DATA WAS FETCHED AND RENDERED ↝ USERS COULDN’T INTERACT WITH THE PAGE UNTIL HYDRATION WAS COMPLETE FOR THE WHOLE PAGE ↝ PARTS OF YOUR APP THAT LOAD FAST WOULD ALWAYS HAVE TO WAIT FOR THE SLOW ONES HYDRATION: BEFORE

Slide 126

Slide 126 text

DEEP DIVING ON CONCURRENT REACT /

Slide 127

Slide 127 text

HYDRATION: BEFORE FETCHING DATA (SERVER) RENDERING HTML (SERVER) LOADING CODE (CLIENT) HYDRATING TIME TO FIRST BYTE FIRST CONTENTFUL PAINT TIME TO INTERACTIVE 127

Slide 128

Slide 128 text

HYDRATION: AFTER 128 TIME TO FIRST BYTE FIRST CONTENTFUL PAINT TIME TO INTERACTIVE […] FETCHING DATA (SERVER) RENDERING HTML (SERVER) HYDRATING LOADING CODE (CLIENT) […] […] […] […] […] […]

Slide 129

Slide 129 text

↝ pipeToNodeStream + createRoot + ↝ REACT PRIORITIZES HYDRATING THE PARTS THAT THE USER INTERACTED WITH BEFORE THE REST ↝ COMPONENTS CAN BECOME INTERACTIVE FASTER BY ALLOWING THE BROWSER TO DO OTHER WORK AT THE SAME TIME AS HYDRATION HYDRATION: AFTER

Slide 130

Slide 130 text

↝ REACT WON'T WAIT FOR HUGE COMPONENTS TO LOAD TO CONTINUE STREAMING HTML FOR THE REST OF THE PAGE ↝ WHEN THE HTML BECOMES AVAILABLE ON THE SERVER, IT WILL BE ADDED TO THE SAME STREAM ALONG WITH A SCRIPT TAG AND INSERTED IN THE RIGHT PLACE HYDRATION: AFTER

Slide 131

Slide 131 text

DEEP DIVING ON CONCURRENT REACT /

Slide 132

Slide 132 text

DEEP DIVING ON CONCURRENT REACT #4 of 4 PROFILER ENHANCEMENTS

Slide 133

Slide 133 text

PROFILER: TRANSITIONS — INTRODUCING A NEW REACT PROFILER, BY BRIAN VAUGHN

Slide 134

Slide 134 text

PROFILER: BLOCKED RENDERS — INTRODUCING A NEW REACT PROFILER, BY BRIAN VAUGHN

Slide 135

Slide 135 text

PROFILER: HINTS — INTRODUCING A NEW REACT PROFILER, BY BRIAN VAUGHN

Slide 136

Slide 136 text

Scheduling on the Web DEEP DIVING ON CONCURRENT REACT /

Slide 137

Slide 137 text

SCHEDULING ON THE WEB WE HAVE A FEW SCHEDULING PRIMITIVES: ↝ setTimeout ↝ requestAnimationFrame ↝ requestIdleCallback ↝ postMessage

Slide 138

Slide 138 text

SCHEDULING ON THE WEB ↝ WE ALL SHOULD USE THE SAME SCHEDULER ↝ HAVING MORE THAN ONE SCHEDULER CAUSES RESOURCE FIGHTING ↝ INTERLEAVING TASKS WITH BROWSER WORK (RENDERING, GARBAGE COLLECTION, ETC.)

Slide 139

Slide 139 text

#rant 😡 We need better and uniform scheduling primitives for the web!

Slide 140

Slide 140 text

DEEP DIVING ON CONCURRENT REACT /

Slide 141

Slide 141 text

SCHEDULING API ↝ A MORE ROBUST SOLUTION FOR SCHEDULING TASKS ↝ INTEGRATED DIRECTLY INTO THE EVENT LOOP ↝ CONTROL AND SCHEDULE PRIORITIZED TASKS IN A UNITED AND FLEXIBLE WAY ↝ ALIGNED WITH THE WORK OF THE REACT TEAM AND IN COOPERATION WITH GOOGLE, W3C AND OTHERS

Slide 142

Slide 142 text

DEEP DIVING ON CONCURRENT REACT /

Slide 143

Slide 143 text

SCHEDULING API scheduler.postTask() SCHEDULE AND CONTROL PRIORITIZING TASKS. scheduler.wait() YIELD AND RESUME AFTER SOME AMOUNT OF TIME OR PERHAPS AFTER AN EVENT HAS OCCURRED. scheduler.yield() BREAK UP LONG TASKS BY YIELDING TO THE BROWSER AND CONTINUING AFTER BEING RESCHEDULED. isInputPending() DETERMINE IF THE CURRENT TASK IS BLOCKING INPUT EVENTS.

Slide 144

Slide 144 text

SCHEDULING API: postTask scheduler.postTask(() = > { console.log('React Brussels'); }, { delay: 10 }); scheduler.postTask(() = > { console.log('React India'); }); scheduler.postTask(() = > { console.log('React Alicante'); }); / / 'React India' 'React Alicante' 'React Brussels'

Slide 145

Slide 145 text

SCHEDULING API: postTask const controller = new TaskController({ priority: "user-blocking" }); const signal = controller.signal; console.log(signal.priority); / / 'user-blocking' console.log(signal.aborted); / / 'false' scheduler.postTask(doWork, { signal }); controller.setPriority("background"); controller.abort();

Slide 146

Slide 146 text

SCHEDULING API: isInputPending while (workQueue.length > 0) { if (navigator.scheduling.isInputPending()) { / / Stop doing work to handle any input event break; } let job = workQueue.shift(); job.execute(); }

Slide 147

Slide 147 text

DEEP DIVING ON CONCURRENT REACT /

Slide 148

Slide 148 text

SCHEDULING API: isInputPending

Slide 149

Slide 149 text

SCHEDULING API: yield async function doWork() { while (true) { let hasMoreWork = doSomeWork(); if (!hasMoreWork) { return; } if (!navigator.scheduling.isInputPending()) { continue; } await scheduler.yield(); } } 🤯

Slide 150

Slide 150 text

SCHEDULING API

Slide 151

Slide 151 text

SCHEDULING: RECAP ↝ SCHEDULING IS AN ALTERNATIVE FOR RESPONSIVE USER INTERFACES ↝ A WEB STANDARDS PROPOSAL THAT BRINGS A UA SCHEDULER TO THE BROWSER IS BEING COOKED ↝ WE CAN SOLVE A LOT AT THE FRAMEWORK LEVEL WITH CONCURRENT REACT AND ITS SCHEDULER

Slide 152

Slide 152 text

#noSilverBullet 🗣 Code that yields too often can cause the overhead of scheduling tasks to become a negative influence on your app’s overall performance.

Slide 153

Slide 153 text

SCHEDULING: BAD PARTS ↝ DETECTION AND SCHEDULING HAVE AN OVERHEAD ↝ NO CORRECT CHUNK SIZE THAT FITS ALL DEVICES ↝ PARTIALLY COMPLETE INTERFACES CAN INCREASE THE TOTAL COST OF LAYOUT AND PAINT ↝ HARD TO FIND THE RIGHT SPOT BETWEEN PERF AND AMOUNT OF BLOCKING 🤯

Slide 154

Slide 154 text

DEEP DIVING ON CONCURRENT REACT /

Slide 155

Slide 155 text

SCHEDULING: BAD PARTS

Slide 156

Slide 156 text

SCHEDULING: BAD PARTS

Slide 157

Slide 157 text

SCHEDULING: BAD PARTS

Slide 158

Slide 158 text

↝ HEAVY COMPONENTS SHOULD BE WRAPPED IN React.memo ↝ THEIR PROPS MEMOIZED WITH useMemo AND useCallback ↝ HEAVY OPERATIONS SHOULD BE MEMOIZED WITH useMemo ↝ isPending SHOULD NOT BE PASSED AS A PROP OR DEPENDENCY TO ANYTHING FROM THE ABOVE SCHEDULING: BAD PARTS

Slide 159

Slide 159 text

SCHEDULING: BAD PARTS

Slide 160

Slide 160 text

Measure DEEP DIVING ON CONCURRENT REACT /

Slide 161

Slide 161 text

MEASURE: LAB

Slide 162

Slide 162 text

MEASURE: FIELD

Slide 163

Slide 163 text

#protip 💡 Start with observability services or libraries like web-vitals. Then create your own abstractions on top of the web + React (e.g. custom hooks).

Slide 164

Slide 164 text

MEASURE: TIMING USER TIMING ALLOWS YOU TO MARK POINTS IN TIME AND THEN MEASURE THE DURATION BETWEEN THOSE MARKS. EVENT TIMING EVENT PROCESSING TIME + TIME UNTIL THE NEXT FRAME CAN BE RENDERED. THE BASIS FOR THE FID METRIC. ELEMENT TIMING MEASURE THE RENDER TIME OF SPECIFIC ELEMENTS. THE BASIS FOR THE LCP METRIC.

Slide 165

Slide 165 text

MEASURE: PROFILING LONG TASKS API REPORTS TASKS THAT TAKES LONGER THAN 50 MS AND IT'S THE BASIS FOR TTI AND TBT METRICS JS SELF-PROFILING API PROFILE SPECIFIC COMPLEX OPERATIONS AND IDENTIFY HOT SPOTS USING A SAMPLING PROFILER UserAgentSpecificMemory DETECT MEMORY LEAKS IN APPS THAT HANDLE A HUGE VOLUME OF DATA

Slide 166

Slide 166 text

MEASURE: PROFILING { name: "same-origin-descendant", entryType: "longtask", startTime: 1023.40999995591, duration: 187.19000002602115, attribution: [ { name: "unknown", entryType: "taskattribution", startTime: 0, duration: 0, containerType: "iframe", containerSrc: "child.html", containerId: "", containerName: "child1" } ] } { bytes: 1000000, breakdown: [ { bytes: 1000000, attribution: [ { url: "https://example.com", scope: "Window", }, ], types: ["JS", "DOM"], }, { bytes: 0, attribution: [], types: [], }, ], } { "frames": [ { "name": "Profiler" }, { "column": 0, "line": 100, "name": "", "resourceId": 0 }, { "name": "set innerHTML" }, { "column": 10, "line": 10, "name": "A", "resourceId": 1 } { "column": 20, "line": 20, "name": "B", "resourceId": 1 } ], "resources": [ "https://example.com/page", "https://example.com/app.js", ], "samples": [ { "stackId": 0, "timestamp": 161.99500000476837 }, { "stackId": 2, "timestamp": 182.43499994277954 }, { "timestamp": 197.43499994277954 }, { "timestamp": 213.32999992370605 }, { "stackId": 3, "timestamp": 228.59999990463257 }, ], "stacks": [ { "frameId": 0 }, { "frameId": 2 }, { "frameId": 3 }, { "frameId": 4, "parentId": 2 } ] } LONG TASKS SELF-PROFILING USERAGENT MEMORY 🤯

Slide 167

Slide 167 text

The Future DEEP DIVING ON CONCURRENT REACT /

Slide 168

Slide 168 text

THE FUTURE ↝ I/O LIBRARIES LIKE react-fetch ↝ BUILT-IN FOR DATA FETCHING LIBRARIES TO INTEGRATE WITH ↝ REACT SERVER COMPONENTS ↝ NATIVE SCHEDULING PRIMITIVES ON THE BROWSER ↝ AND MUCH MORE! 🤯

Slide 169

Slide 169 text

DEEP DIVING ON CONCURRENT REACT / OFFSCREEN

Slide 170

Slide 170 text

OFFSCREEN: RECAP ↝ RENDERING IN THE BACKGROUND WITH NO ADDITIONAL PERFORMANCE OVERHEAD ↝ IT DOESN'T ACTUALLY MOUNT UNTIL THE COMPONENT BECOMES VISIBLE AND ITS EFFECTS ARE NOT FIRED ↝ TOGGLE THE VISIBILITY WITHOUT LOSING STATE ↝ INTEGRATED INTO ROUTERS AND OTHER UI LIBRARIES

Slide 171

Slide 171 text

OFFSCREEN: USE CASES ↝ ROUTERS CAN PRERENDER SCREENS IN THE BACKGROUND SO THAT THEY’RE INSTANTLY AVAILABLE. ↝ TAB SWITCHING CAN PRESERVE THE STATE OF HIDDEN TABS, SO THE USER CAN SWITCH BETWEEN THEM WITHOUT LOSING THEIR PROGRESS. ↝ VIRTUALIZED LIST CAN PRERENDER ADDITIONAL ROWS ABOVE AND BELOW THE VISIBLE WINDOW.

Slide 172

Slide 172 text

DEEP DIVING ON CONCURRENT REACT / SUSPENSE FOR CPU-BOUND TREES

Slide 173

Slide 173 text

DEEP DIVING ON CONCURRENT REACT /

Slide 174

Slide 174 text

SUSPENSE FOR CPU-BOUND TREES ↝ FORCES A FALLBACK ON THE INITIAL RENDER REGARDLESS OF WHETHER SOMETHING IS SUSPENDED. ↝ DURING THE INITIAL MOUNT, REACT WILL SKIP OVER EXPENSIVE TREES BY RENDERING A PLACEHOLDER. ↝ IT HELPS UNBLOCK THE INITIAL SKELETON FOR THE NEW SCREEN.

Slide 175

Slide 175 text

DEEP DIVING ON CONCURRENT REACT / TRANSITION TRACING

Slide 176

Slide 176 text

TRANSITION TRACING ↝ USE THE PROFILER API AND DEVTOOLS PROFILER/ TIMELINE TO WATCH FOR PERFORMANCE REGRESSIONS FOR SPECIFIC TRANSITIONS. ↝ DETECT WHEN TRANSITIONS BECOME SLOWER AND INVESTIGATE WHY THEY MAY BE SLOW. ↝ A NEW VERSION OF THE INTERACTION TRACING API.

Slide 177

Slide 177 text

DEEP DIVING ON CONCURRENT REACT /

Slide 178

Slide 178 text

Slide 179

Slide 179 text

const onTransitionStart = (transitionName, startTime) = > . . . ; const onTransitionComplete = (transitionName, startTime, endTime) = > . . . ; const onTransitionProgress = (transitionName, startTime, currentTime, pendingSuspenseBoundaries) = > . . . ; const root = React.createRoot(container, { transitionCallbacks: { onTransitionStart, onTransitionComplete, onTransitionProgress, }, }); TRANSITION TRACING — TRANSITION TRACING API RFC

Slide 180

Slide 180 text

function Profile({ id }) { return ( }>

Photos

Profile Feed

}> ); } TRANSITION TRACING — TRANSITION TRACING API RFC

Slide 181

Slide 181 text

DEEP DIVING ON CONCURRENT REACT / OPTIMIZING COMPILER

Slide 182

Slide 182 text

DEEP DIVING ON CONCURRENT REACT /

Slide 183

Slide 183 text

OPTIMIZING COMPILER ↝ IMPROVE THE RENDERING PERFORMANCE BY AUTOMATICALLY GENERATING THE EQUIVALENT OF useMemo AND useCallback CALLS. ↝ MINIMIZE THE COST OF RE-RENDERING WHILE RETAINING REACT’S PROGRAMMING MODEL. ↝ AUTOMATIC REACTIVITY COMPILER.

Slide 184

Slide 184 text

Closing Notes DEEP DIVING ON CONCURRENT REACT /

Slide 185

Slide 185 text

DEEP DIVING ON CONCURRENT REACT /

Slide 186

Slide 186 text

DEEP DIVING ON CONCURRENT REACT / #1 of 8 REACT IS NOT REACTIVE, BUT IT IS CONCURRENT AND THAT MIGHT BE ENOUGH FOR YOU

Slide 187

Slide 187 text

No content

Slide 188

Slide 188 text

DEEP DIVING ON CONCURRENT REACT / #2 of 8 REACT HAS BEEN PUSHING WEB APIS TO THE FUTURE E.G. THE SCHEDULER API AND DISCUSSIONS AROUND EFFECT HANDLERS

Slide 189

Slide 189 text

DEEP DIVING ON CONCURRENT REACT / #3 of 8 REACT TRIES TO ADDRESS THE LACK OF SOME JS/WEB PLATFORM RESOURCES E.G. EFFECT HANDLERS, CONTINUATIONS & THE SCHEDULER API

Slide 190

Slide 190 text

DEEP DIVING ON CONCURRENT REACT / #4 of 8 UNDERSTANDING THESE INTERNALS AND THEIR RATIONALES HELPS US IMPLEMENT OUR OWN ABSTRACTIONS E.G. THE GENERATOR-BASED SCHEDULER & FIRST CLASS SUPPORT FOR PROMISES

Slide 191

Slide 191 text

DEEP DIVING ON CONCURRENT REACT /

Slide 192

Slide 192 text

CLOSING NOTES: REACT USE

Slide 193

Slide 193 text

CLOSING NOTES: REACT USE

Slide 194

Slide 194 text

CLOSING NOTES: REACT USE 🤯

Slide 195

Slide 195 text

export const Hello = () = > { const value = usePromise(() = > delay("Hey there! 👋", 3000)); return {value}; }; function Demo() { return ( }> ); } 🤯

Slide 196

Slide 196 text

DID WE JUST CREATE React.use()? 🤔

Slide 197

Slide 197 text

YES, WE DID 🤓

Slide 198

Slide 198 text

No content

Slide 199

Slide 199 text

DEEP DIVING ON CONCURRENT REACT / #5 of 8 SCHEDULING DOES NOT NECESSARILY MEAN BETTER PERFORMANCE

Slide 200

Slide 200 text

DEEP DIVING ON CONCURRENT REACT / #5 of 8 SCHEDULING DOES NOT NECESSARILY MEAN BETTER PERFORMANCE ↝ NON-URGENT UPDATES TAKE LONGER ↝ CAN’T HELP SOME EXPENSIVE COMPONENTS ↝ EXTRA CPU COST 🤯

Slide 201

Slide 201 text

DEEP DIVING ON CONCURRENT REACT / #6 of 8 THERE'S NO SILVER BULLET. IDENTIFY YOUR CORE METRICS.

Slide 202

Slide 202 text

DEEP DIVING ON CONCURRENT REACT / #7 of 8 THERE’S A LOT OF INFORMATION OUT THERE

Slide 203

Slide 203 text

No content

Slide 204

Slide 204 text

DEEP DIVING ON CONCURRENT REACT / #8 of 8 ALWAYS TRY TO CORRELATE BUSINESS METRICS WITH PERFORMANCE

Slide 205

Slide 205 text

THAT’S ALL, FOLKS! THANKS! 👋 🇩🇪 QUESTIONS? MATHEUS ALBUQUERQUE • @ythecombinator ↑ ALL THE LINKS!