🇩🇪 iJS Munich 2023 - Deep diving on Concurrent React

Writing fluid user interfaces becomes more and more challenging as the application complexity increases. In this talk, we’ll explore how proper scheduling improves your app’s experience by diving into some concurrent React features, understanding their rationales, and how they work under the hood.

Transcript

1. Hello, Munich! 👋 🇩🇪 DEEP DIVING ON CONCURRENT REACT • THE 24TH OF OCTOBER, 2023.
2. DEEP DIVING ON CONCURRENT REACT MATHEUS ALBUQUERQUE • @ythecombinator
3. ↑ ALL THE LINKS! 🧑🏫 TECHLABS 🐦 @ythecombinator 👨💻 MEDALLIA ⚡ PERF GDE SPEED AT SCALE: OPTIMIZING THE LARGEST CX PLATFORM OUT THERE /
4. #question 🤔 Who here works with front-end? And React?
5. #heads-up 🥱 60 minutes is a lot of time, I know…
7. Preamble DEEP DIVING ON CONCURRENT REACT /
8. DEEP DIVING ON CONCURRENT REACT /
9. WE TALKED ABOUT… ↝ FIBERS ↝ COROUTINES ↝ GENERATORS ↝ ALGEBRAIC EFFECTS
10. WE TALKED ABOUT… ↝ FIBERS ↝ COROUTINES ↝ GENERATORS ↝ ALGEBRAIC EFFECTS I WANTED TO DISCUSS MORE… ↝ VIRTUAL DOM ↝ CONCURRENCY/PARALLELISM ↝ CONCURRENT REACT ↝ MEASUREMENT
11. 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
12. 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
13. DEEP DIVING ON CONCURRENT REACT /
14. #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
15. 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
16. PERF MITIGATORS ↝ shouldComponentUpdate, React.PureComponent ↝ React.memo ↝ useMemo, useCallback ↝ useTransition, useDeferredValue, React.Suspense & others
17. #protip 💡 React doesn’t have any understanding of the values running through your app. It’s not reactive.
18. VIRTUAL DOM
19. VIRTUAL DOM
20. 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)
21. 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
22. #question 🤔 Why do we even bother discussing Concurrent React?
23. PERFOMANCE
24. 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?
25. 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?
26. LONG TASKS
27. LONG TASKS
28. LONG TASKS
29. LONG TASKS
30. #research 📚 Phone users experience slow First Input Delay on 7x more websites. — Web Almanac By HTTP Archive, 2021
31. FIRST INPUT DELAY DESKTOP PHONE 0 25 50 75 100 SLOW ( > = 250MS) AVERAGE FAST (<50 MS)
32. 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
33. BUSINESS OUTCOMES — AKAMAI AND CHROME RESEARCH, 2017
34. #answer 💡 That’s why we do bother discussing Concurrent React!
35. #question 🤔 If you were to summarize Concurrent React in one word/expression, what’d be your pick?
36. #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 ↝ ???
37. If you were to summarize Concurrent React in one word/expression, what’d be your pick? DEEP DIVING ON CONCURRENT REACT /
38. The Main Thread DEEP DIVING ON CONCURRENT REACT /
39. TASKS A UNIT OF WORK THAT THE BROWSER DOES TO RENDER A FRAME JAVASCRIPT STYLES LAYOUT PAINT COMPOSITE
40. TASKS JAVASCRIPT STYLES LAYOUT PAINT COMPOSITE
41. 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
42. #QUESTION 🤔 How to avoid blocking the main thread?
43. 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
44. TASK RUNNING STRATEGIES A B C D
45. TASK RUNNING STRATEGIES PARALLELISM CONCURRENCY SCHEDULING
46. TASK RUNNING STRATEGIES PARALLELISM CONCURRENCY SCHEDULING
47. 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
48. 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 🤯
49. 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 🤯
50. 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 🤯
51. 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 🤯
52. 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 🤯
53. 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
54. 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
55. ↝ Atomics ↝ BuffferBackedObject ↝ Comlink ↝ WorkerDOM ↝ Partytown ↝ AND MUCH MORE!
56. WORKERS ↝ GOOD FOR DATA PROCESSING AND CRUNCHING NUMBERS ↝ HARD TO USE FOR UI-RELATED STUFF ↝ HARDER THAN ADJUSTING IT FOR A SCHEDULER
57. TASK RUNNING STRATEGIES PARALLELISM CONCURRENCY SCHEDULING
58. If you were to summarize Concurrent React in one word/expression, what’d be your pick? DEEP DIVING ON CONCURRENT REACT /
59. Scheduling in React DEEP DIVING ON CONCURRENT REACT /
60. 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
61. 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 <p>{result}</p>; }
62. DEEP DIVING ON CONCURRENT REACT /
63. #question 🤔 How could we improve that?
64. DEEP DIVING ON CONCURRENT REACT /
65. REDUX-SAGA
66. 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 <p>{result}</p>; }
67. 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 <p>{result}</p>; }
68. 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 <p>{result}</p>; } PROMOTED TO A GENERATOR YIELDING EXECUTION DOING CONCURRENT TASKS
69. DEEP DIVING ON CONCURRENT REACT /
70. enum SchedulerState { IDLE = "IDLE", PENDING = "PENDING", DONE = "DONE", } class Scheduler<T> { 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; } } }
71. 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; } }
72. DID WE JUST useTransition’ED? 🤔
73. 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 <p>{result}</p>; }
74. 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 [_, startTransition] = useTransition(); const [result, setResult] = useState(""); useEffect(() = > { startTransition(() = > { const newResult = resourcefulOperation(props.value); setResult(newResult); }); }, [props.value]); return <p>{result}</p>; }
75. YES, WE DID 🤓 WITH OUR OWN SCHEDULER
76. 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
77. HEURISTICS ↓ ORIGINAL RENDER TASK USER INPUT → ↑ HIGHER PRIORITY RENDER TASK ↓ RESUME ORIGINAL RENDER TASK
78. HEURISTICS
79. HEURISTICS
80. 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
81. BRANCHING WORKFLOW — EVERYTHING YOU NEED TO KNOW ABOUT CONCURRENT REACT (WITH A LITTLE BIT OF SUSPENSE) • HENRIQUE YUJI
82. BRANCHING WORKFLOW — EVERYTHING YOU NEED TO KNOW ABOUT CONCURRENT REACT (WITH A LITTLE BIT OF SUSPENSE) • HENRIQUE YUJI
83. BRANCHING WORKFLOW — EVERYTHING YOU NEED TO KNOW ABOUT CONCURRENT REACT (WITH A LITTLE BIT OF SUSPENSE) • HENRIQUE YUJI
84. PRIORITY LEVELS
85. PRIORITY LEVELS
86. 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)
87. 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. 🤯
88. 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 🤯
91. #question 🤔 How do we benefit from these in our everyday projects?
92. Scheduling in React (For the Rest of Us) DEEP DIVING ON CONCURRENT REACT /
93. 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!
94. HANDLING LARGE SETS OF DATA DEEP DIVING ON CONCURRENT REACT #1 of 4
95. HANDLING LARGE SETS OF DATA 😔 NON-PRACTICAL… ↝ FINDING PRIMES ↝ CRACKING PASSWORDS ↝ SIERPINSKI TRIANGLE 😊 PRACTICAL… ↝ RENDERING MANY DATA-POINTS ↝ RENDERING ON A <canvas> ↝ PROCESSING DATA
96. HANDLING LARGE SETS OF DATA 😔 NON-PRACTICAL… ↝ FINDING PRIMES ↝ CRACKING PASSWORDS ↝ SIERPINSKI TRIANGLE 😊 PRACTICAL… ↝ RENDERING MANY DATA-POINTS ↝ RENDERING ON A <canvas> ↝ PROCESSING DATA
97. DAILY VISITORS: BEFORE
98. DAILY VISITORS: BEFORE const DailyVisitors = () = > { const [data, setData] = useState(initialData); useEffect(() = > { setData(initialData); }, []); const onChange = (newData) = > { setData(newData); }; return ( <Dashboard data={data} initialData={initialData} onChange={onChange} /> ); }; export default DailyVisitors;
99. DAILY VISITORS: BEFORE const DailyVisitors = () = > { const [data, setData] = useState(initialData); const [, startTransition] = useTransition(); useEffect(() = > { setData(initialData); }, []); const onChange = (newData) = > { startTransition(() = > { setData(newData); }); }; return ( <Dashboard data={data} initialData={initialData} onChange={onChange} /> ); }; export default DailyVisitors;
100. DAILY VISITORS: AFTER
101. ↝ ˜100K DATA POINTS PLOTTED ↝ SUPPORT FOR SEARCHING AND FILTERING ↝ USED WORKERS + REDUX-SAGA UTILITIES + DEBOUNCING ↝ COULD'VE USED TRANSITIONS LOCATION DATA #1 of 2
102. ↝ 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
103. DEEP DIVING ON CONCURRENT REACT /
104. REAL WORLD EXAMPLE
105. FAST COMPUTER: NO TRANSITIONS
106. FAST COMPUTER: WITH TRANSITIONS
107. SLOW COMPUTER: NO TRANSITIONS
108. SLOW COMPUTER: WITH TRANSITIONS
109. DEEP DIVING ON CONCURRENT REACT #2 of 4 TACKLING WASTED RENDERS
110. useSyncExternalStore function useSyncExternalStore<Snapshot>( subscribe: (onStoreChange: () = > void) = > () = > void, getSnapshot: () = > Snapshot, getServerSnapshot?: () = > Snapshot ): Snapshot;
111. DEEP DIVING ON CONCURRENT REACT /
112. DEEP DIVING ON CONCURRENT REACT /
113. useSyncExternalStore
114. useSyncExternalStore
115. #question 🤔 How do we benefit from these in our everyday projects?
117. useLocation function Pathname() { const { pathname } = useLocation(); return <Badge title={pathname} subtitle="pathname" />; } function Hash() { const { hash } = useLocation(); return <Badge title={hash} subtitle="hash" />; }
118. useLocation function Pathname() { const { pathname } = useLocation(); return <Badge title={pathname} subtitle="pathname" />; } function Hash() { const { hash } = useLocation(); return <Badge title={hash} subtitle="hash" />; } OVER-RETURNING HOOK
119. SPEAKERS LIST: BEFORE
120. useHistorySelector function useHistorySelector(selector) { const history = useHistory(); return useSyncExternalStore(history.listen, () = > selector(history)); } function Pathname() { const pathname = useHistorySelector((history) = > history.location.pathname); return <Badge title={pathname} subtitle="pathname" />; } function Hash() { const hash = useHistorySelector((history) = > history.location.hash); return <Badge title={hash} subtitle="hash" />; }
121. useHistorySelector function useHistorySelector(selector) { const history = useHistory(); return useSyncExternalStore(history.listen, () = > selector(history)); } function Pathname() { const pathname = useHistorySelector((history) = > history.location.pathname); return <Badge title={pathname} subtitle="pathname" />; } function Hash() { const hash = useHistorySelector((history) = > history.location.hash); return <Badge title={hash} subtitle="hash" />; }
122. SPEAKERS LIST: AFTER
123. DEEP DIVING ON CONCURRENT REACT #3 of 4 HYDRATION IMPROVEMENTS
124. HYDRATION: BEFORE FETCHING DATA (SERVER) RENDERING HTML (SERVER) LOADING CODE (CLIENT) HYDRATING TIME TO FIRST BYTE FIRST CONTENTFUL PAINT TIME TO INTERACTIVE 124
125. ↝ 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
126. DEEP DIVING ON CONCURRENT REACT /
127. HYDRATION: BEFORE FETCHING DATA (SERVER) RENDERING HTML (SERVER) LOADING CODE (CLIENT) HYDRATING TIME TO FIRST BYTE FIRST CONTENTFUL PAINT TIME TO INTERACTIVE 127
128. HYDRATION: AFTER 128 TIME TO FIRST BYTE FIRST CONTENTFUL PAINT TIME TO INTERACTIVE […] FETCHING DATA (SERVER) RENDERING HTML (SERVER) HYDRATING LOADING CODE (CLIENT) […] […] […] […] […] […]
129. ↝ pipeToNodeStream + createRoot + <Suspense> ↝ 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
130. ↝ 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
131. DEEP DIVING ON CONCURRENT REACT /
132. DEEP DIVING ON CONCURRENT REACT #4 of 4 PROFILER ENHANCEMENTS
133. PROFILER: TRANSITIONS — INTRODUCING A NEW REACT PROFILER, BY BRIAN VAUGHN
134. PROFILER: BLOCKED RENDERS — INTRODUCING A NEW REACT PROFILER, BY BRIAN VAUGHN
135. PROFILER: HINTS — INTRODUCING A NEW REACT PROFILER, BY BRIAN VAUGHN
136. Scheduling on the Web DEEP DIVING ON CONCURRENT REACT /
137. SCHEDULING ON THE WEB WE HAVE A FEW SCHEDULING PRIMITIVES: ↝ setTimeout ↝ requestAnimationFrame ↝ requestIdleCallback ↝ postMessage
138. 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.)
139. #rant 😡 We need better and uniform scheduling primitives for the web!
140. DEEP DIVING ON CONCURRENT REACT /
141. 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
142. DEEP DIVING ON CONCURRENT REACT /
143. 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.
144. 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'
145. 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();
146. 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(); }
147. DEEP DIVING ON CONCURRENT REACT /
148. SCHEDULING API: isInputPending
149. SCHEDULING API: yield async function doWork() { while (true) { let hasMoreWork = doSomeWork(); if (!hasMoreWork) { return; } if (!navigator.scheduling.isInputPending()) { continue; } await scheduler.yield(); } } 🤯
150. SCHEDULING API
151. 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
152. #noSilverBullet 🗣 Code that yields too often can cause the overhead of scheduling tasks to become a negative influence on your app’s overall performance.
153. 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 🤯
154. DEEP DIVING ON CONCURRENT REACT /
155. SCHEDULING: BAD PARTS
156. SCHEDULING: BAD PARTS
157. SCHEDULING: BAD PARTS
158. ↝ 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
159. SCHEDULING: BAD PARTS
160. Measure DEEP DIVING ON CONCURRENT REACT /
161. MEASURE: LAB
162. MEASURE: FIELD
163. #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).
164. 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.
165. 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
166. 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 🤯
167. The Future DEEP DIVING ON CONCURRENT REACT /
168. THE FUTURE ↝ I/O LIBRARIES LIKE react-fetch ↝ BUILT-IN <Cache> FOR DATA FETCHING LIBRARIES TO INTEGRATE WITH <Suspense> ↝ REACT SERVER COMPONENTS ↝ NATIVE SCHEDULING PRIMITIVES ON THE BROWSER ↝ AND MUCH MORE! 🤯
169. DEEP DIVING ON CONCURRENT REACT / OFFSCREEN
170. 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
171. 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.
172. DEEP DIVING ON CONCURRENT REACT / SUSPENSE FOR CPU-BOUND TREES
173. DEEP DIVING ON CONCURRENT REACT /
174. 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.
175. DEEP DIVING ON CONCURRENT REACT / TRANSITION TRACING
176. 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.
177. DEEP DIVING ON CONCURRENT REACT /
178. function App() { const user = getViewingUser(); const [pageName, setPageName] = useState("homefeed"); const onNavigate = (pageName) = > { startTransition(() = > setPageName(pageName), { name: pageName }); }; return ( <> <NavBar onNavigate={onNavigate} /> <Page name={pageName} id={user.id} /> </> ); } TRANSITION TRACING — TRANSITION TRACING API RFC
179. 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
180. function Profile({ id }) { return ( <TracingMarker name="profile"> <Suspense fallback={<LoadingSpinner />}> <ProfileHeader id={id} /> <TracingMarker name="profile:photo-feed"> <div>Photos</div> <Suspense fallback={<LoadingFeed />}> <PhotoFeed /> </Suspense> </TracingMarker> <TracingMarker name="profile:profile-feed"> <div>Profile Feed</div> <Suspense fallback={<LoadingFeed />}> <ProfileFeed /> </Suspense> </TracingMarker> </Suspense> </TracingMarker> ); } TRANSITION TRACING — TRANSITION TRACING API RFC
181. DEEP DIVING ON CONCURRENT REACT / OPTIMIZING COMPILER
182. DEEP DIVING ON CONCURRENT REACT /
183. 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.
184. Closing Notes DEEP DIVING ON CONCURRENT REACT /
185. DEEP DIVING ON CONCURRENT REACT /
186. DEEP DIVING ON CONCURRENT REACT / #1 of 8 REACT IS NOT REACTIVE, BUT IT IS CONCURRENT AND THAT MIGHT BE ENOUGH FOR YOU
188. 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
189. 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
190. 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
191. DEEP DIVING ON CONCURRENT REACT /
192. CLOSING NOTES: REACT USE
193. CLOSING NOTES: REACT USE
194. CLOSING NOTES: REACT USE 🤯
195. export const Hello = () = > { const value = usePromise(() = > delay("Hey there! 👋", 3000)); return <Typography variant="h3">{value}</Typography>; }; function Demo() { return ( <Grid container justifyContent="center"> <Suspense fallback={<Loading message="Loading . . . " />}> <Hello /> </Suspense> </Grid> ); } 🤯
196. DID WE JUST CREATE React.use()? 🤔
197. YES, WE DID 🤓
199. DEEP DIVING ON CONCURRENT REACT / #5 of 8 SCHEDULING DOES NOT NECESSARILY MEAN BETTER PERFORMANCE
200. 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 🤯
201. DEEP DIVING ON CONCURRENT REACT / #6 of 8 THERE'S NO SILVER BULLET. IDENTIFY YOUR CORE METRICS.
202. DEEP DIVING ON CONCURRENT REACT / #7 of 8 THERE’S A LOT OF INFORMATION OUT THERE
204. DEEP DIVING ON CONCURRENT REACT / #8 of 8 ALWAYS TRY TO CORRELATE BUSINESS METRICS WITH PERFORMANCE
205. THAT’S ALL, FOLKS! THANKS! 👋 🇩🇪 QUESTIONS? MATHEUS ALBUQUERQUE • @ythecombinator ↑ ALL THE LINKS!