$30 off During Our Annual Pro Sale. View Details »

๐Ÿ‡ฎ๐Ÿ‡ณ React India 2022

๐Ÿ‡ฎ๐Ÿ‡ณ React Indiaย 2022

โ„น๏ธ Deep diving on Concurrent React

Writing fluid user interfaces become 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.

Matheus Albuquerque

September 23, 2022
Tweet

More Decks by Matheus Albuquerque

Other Decks in Technology

Transcript

  1. Hello, React India ๐Ÿ™‹ ๐Ÿ‡ฎ๐Ÿ‡ณ ๐ŸŒ DEEP DIVING ON CONCURRENT

    REACT โ€ข THE 23RD OF SEPTEMBER, 2022.
  2. DEEP DIVING ON CONCURRENT REACT MATHEUS ALBUQUERQUE

  3. ร… Iโ€™M MATHEUS ๐Ÿ™‹ โ† @YTHECOMBINATOR ON THE WEB โ†

    SR. SOFTWARE ENGINEER @MEDALLIA โ† MENTOR @TECHLABS
  4. Disclaimers DEEP DIVING ON CONCURRENT REACT

  5. #1 REACT SOURCE CODE IS CONSTANTLY CHANGING, AND SOME THOUGHTS

    ARE SPECULATIVE DEEP DIVING ON CONCURRENT REACT
  6. #2 ๐Ÿคฏ = FURTHER DISCUSSIONS AFTER THE SESSION DEEP DIVING

    ON CONCURRENT REACT
  7. Prologue DEEP DIVING ON CONCURRENT REACT

  8. DEEP DIVING ON CONCURRENT REACT

  9. WE TALKED ABOUTโ€ฆ โ† FIBERS โ† COROUTINES โ† GENERATORS โ†

    ALGEBRAIC EFFECTS
  10. WE TALKED ABOUTโ€ฆ โ† VIRTUAL DOM โ† CONCURRENCY/PARALLELISM โ† CONCURRENT

    REACT โ† MEASUREMENT
  11. DATA-DRIVEN UI LIBS 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 LIBS
  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. โ† 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 VIRTUAL DOM
  16. โ† shouldComponentUpdate, React.PureComponent โ† React.memo โ† useMemo, useCallback โ† useTransition,

    useDeferredValue, React.Suspense & others PERF MITIGATORS
  17. #PROTIP ๐Ÿ’ก React doesnโ€™t have any understanding of the values

    running through your app. Itโ€™s not reactive.
  18. None
  19. None
  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. None
  27. LONG TASKS

  28. None
  29. PHONE USERS EXPERIENCE SLOW FIRST INPUT DELAY ON 7X MORE

    WEBSITES. โ€”โ€‰Web Almanac By HTTP Archive, 2021
  30. DESKTOP PHONE 0 25 50 75 100 SLOW ( >

    = 250MS) AVERAGE FAST (<50 MS) FIRST INPUT DELAY
  31. 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
  32. โ€”โ€‰AKAMAI AND CHROME RESEARCH, 2017 BUSINESS OUTCOMES

  33. #ANSWER ๐Ÿ’ก Thatโ€™s why we do bother discussing Concurrent React!

  34. #QUESTION ๐Ÿค” If you were to summarize Concurrent React in

    one word/expression, whatโ€™d be your pick?
  35. #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 โ† ???
  36. DEEP DIVING ON CONCURRENT REACT If you were to summarize

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

    Concurrent React in one word/expression, whatโ€™d be your pick? 1st/2nd/3rd ANSWERS โ† REACT BRUSSELS DISCOUNT CODE ๐Ÿ‡ง๐Ÿ‡ช OTHERS โ† STICKERS ๐Ÿ’…
  38. The Main Thread DEEP DIVING ON CONCURRENT REACT

  39. TASKS JAVASCRIPT STYLES LAYOUT PAINT COMPOSITE A UNIT OF WORK

    THAT THE BROWSER DOES TO RENDER A FRAME
  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. PARALLELISM โ† MULTIPLE THREADS = MULTIPLE TASKS AT THE SAME

    TIME ON SEPARATE CPU CORES CONCURRENCY โ† SINGLE THREAD + QUICKLY SWITCHING BETWEEN TASKS SCHEDULING โ† CONCURRENCY + TASK PRIORITIZATION TASK RUNNING STRATEGIES
  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. 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. 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. 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. 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. 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. 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

  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. #QUESTION ๐Ÿค” If you were to summarize Concurrent React in

    one word/expression, whatโ€™d be your pick?
  59. DEEP DIVING ON CONCURRENT REACT If you were to summarize

    Concurrent React in one word/expression, whatโ€™d be your pick?
  60. Scheduling in React DEEP DIVING ON CONCURRENT REACT

  61. 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. None
  66. 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. โ† 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 SCHEDULING
  77. โ†“ ORIGINAL RENDER TASK USER INPUT โ†’ โ†‘ HIGHER PRIORITY

    RENDER TASK โ†“ RESUME ORIGINAL RENDER TASK
  78. โ† 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 SCHEDULING
  79. PRIORITY LEVELS

  80. PRIORITY LEVELS

  81. 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)
  82. โ† 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. RENDER LANES ๐Ÿคฏ
  83. โ† 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 RENDER LANES ๐Ÿคฏ
  84. None
  85. DEEP DIVING ON CONCURRENT REACT

  86. #QUESTION ๐Ÿค” How do we benefit from these in our

    everyday projects?
  87. Scheduling in React [for the rest of us] DEEP DIVING

    ON CONCURRENT REACT
  88. #1 HANDLING LARGE SETS OF DATA DEEP DIVING ON CONCURRENT

    REACT
  89. ๐Ÿ˜” NON-PRACTICALโ€ฆ โ† FINDING PRIMES โ† CRACKING PASSWORDS โ† SIERPINSKI

    TRIANGLE
  90. ๐Ÿ˜” NON-PRACTICALโ€ฆ โ† RENDERING MANY DATA-POINTS โ† RENDERING ON A

    <canvas> โ† PROCESSING DATA
  91. DAILY VISITORS (BEFORE)

  92. 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;
  93. DAILY VISITORS (AFTER) 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;
  94. DAILY VISITORS (AFTER)

  95. โ† หœ100K + POINTS PLOTTED โ† SUPPORT FOR SEARCHING AND

    FILTERING โ† USED WORKERS + REDUX-SAGA UTILITIES + DEBOUNCING โ† COULD'VE USED TRANSITIONS CASE #1: MAPS
  96. CASE #2: GAME ADMIN โ† THOUSANDS OF REAL-TIME PLAYERS MESSAGING

    โ† SUPPORT FOR SEARCHING AND FILTERING โ† USED VIRTUALIZATION AND MEMOIZATION โ† COULD'VE USED TRANSITIONS
  97. #2 TACKLING WASTED RENDERS DEEP DIVING ON CONCURRENT REACT

  98. useSyncExternalStore() function useSyncExternalStore<Snapshot>( subscribe: (onStoreChange: () = > void) =

    > () = > void, getSnapshot: () = > Snapshot, getServerSnapshot?: () = > Snapshot ): Snapshot;
  99. DEEP DIVING ON CONCURRENT REACT

  100. DEEP DIVING ON CONCURRENT REACT

  101. None
  102. None
  103. #QUESTION ๐Ÿค” How do we benefit from these in our

    everyday projects?
  104. useLocation() function Pathname() { const { pathname } = useLocation();

    return <Badge title={pathname} subtitle="pathname" />; } function Hash() { const { hash } = useLocation(); return <Badge title={hash} subtitle="hash" />; }
  105. 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
  106. None
  107. useHistory() + useSyncExternalStore() 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" />; }
  108. 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" />; } useHistory() + useSyncExternalStore()
  109. None
  110. #3 HYDRATION IMPROVEMENTS DEEP DIVING ON CONCURRENT REACT

  111. โ† BEFORE, 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
  112. SELECTIVE HYDRATION <Layout> <Article /> <Suspense fallback={<Spinner />}> <Co m

    m ents /> </Suspense> </Layout>
  113. โ† REACT WON'T WAIT FOR THAT COMPONENT 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 SELECTIVE HYDRATION
  114. โ† 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 โ† RESULTS IN LOWER FID AND INP SELECTIVE HYDRATION
  115. DEEP DIVING ON CONCURRENT REACT

  116. #4 PROFILER ENHANCEMENTS DEEP DIVING ON CONCURRENT REACT

  117. TRANSITIONS โ€” INTRODUCING A NEW REACT PROFILER, BY BRIAN VAUGHN

  118. โ€” INTRODUCING A NEW REACT PROFILER, BY BRIAN VAUGHN BLOCKED

    RENDER
  119. โ€” INTRODUCING A NEW REACT PROFILER, BY BRIAN VAUGHN WARNS

  120. Scheduling on the Web DEEP DIVING ON CONCURRENT REACT

  121. WE HAVE A FEW SCHEDULING PRIMITIVES: โ† setTimeout โ† requestAnimationFrame

    โ† requestIdleCallback โ† postMessage SCHEDULING ON THE WEB
  122. โ† EVERYONE SHOULD USE THE SAME SCHEDULER โ† HAVING MORE

    THAN ONE SCHEDULER CAUSES RESOURCE FIGHTING โ† INTERLEAVING TASKS WITH BROWSER WORK (RENDERING, GARBAGE COLLECTION) SCHEDULING ON THE WEB
  123. #RANT ๐Ÿ˜ก We need better and uniform scheduling primitives for

    the web!
  124. DEEP DIVING ON CONCURRENT REACT

  125. 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
  126. DEEP DIVING ON CONCURRENT REACT

  127. 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. SCHEDULING API
  128. scheduler.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'
  129. scheduler.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();
  130. isInputPending() while (workQueue.length > 0) { if (navigator.scheduling.isInputPending()) { /

    / Stop doing work to handle any input event break; } let job = workQueue.shift(); job.execute(); }
  131. scheduler.yield() async function doWork() { while (true) { let hasMoreWork

    = doSomeWork(); if (!hasMoreWork) { return; } if (!navigator.scheduling.isInputPending()) { continue; } await scheduler.yield(); } } ๐Ÿคฏ
  132. SCHEDULING API

  133. โ† 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 SCHEDULING (RECAP)
  134. #NOSILVERBULLET ๐Ÿ”ซ Code that yields too often can cause the

    overhead of scheduling tasks to become a negative influence on your appโ€™s overall performance.
  135. โ† 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 SCHEDULING (BAD PARTS) ๐Ÿคฏ
  136. Measure DEEP DIVING ON CONCURRENT REACT

  137. MEASURE IN THE LAB

  138. MEASURE IN THE FIELD

  139. #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).
  140. 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.
  141. 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
  142. { 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 ๐Ÿคฏ
  143. The Future DEEP DIVING ON CONCURRENT REACT

  144. โ† I/O LIBRARIES LIKE react-fetch โ† BUILT-IN <Cache> FOR DATA

    FETCHING LIBRARIES TO INTEGRATE WITH <Suspense> โ† <Suspense> FOR CPU-BOUND TREES TO IMMEDIATELY FALLBACK WITHOUT EVEN TRYING TO RENDER THE FUTURE ๐Ÿคฏ
  145. โ† useInsertionEffect FOR STYLESHEET LIBRARIES โ† THE <Offscreen> COMPONENT โ†

    SERVER COMPONENTS โ† NATIVE SCHEDULING PRIMITIVES ON THE BROWSER โ† AND MUCH MORE! THE FUTURE ๐Ÿคฏ
  146. Closing Notes DEEP DIVING ON CONCURRENT REACT

  147. #1 DEEP DIVING ON CONCURRENT REACT REACT HAS BEEN PUSHING

    WEB APIS TO THE FUTURE E.G. THE SCHEDULER API AND DISCUSSIONS AROUND EFFECT HANDLERS
  148. #2 DEEP DIVING ON CONCURRENT REACT REACT TRIES TO ADDRESS

    THE LACK OF SOME JS/WEB PLATFORM RESOURCES E.G. EFFECT HANDLERS, CONTINUATIONS & THE SCHEDULER API
  149. #3 DEEP DIVING ON CONCURRENT REACT UNDERSTANDING THESE INTERNALS AND

    THEIR RATIONALES HELPS US IMPLEMENT OUR OWN ABSTRACTIONS E.G. THE GENERATOR-BASED SCHEDULER
  150. #4 DEEP DIVING ON CONCURRENT REACT SCHEDULING DOES NOT NECESSARILY

    MEAN BETTER PERFORMANCE
  151. #4 DEEP DIVING ON CONCURRENT REACT THERE'S NO SILVER BULLET.

    IDENTIFY YOUR CORE METRICS.
  152. #5 DEEP DIVING ON CONCURRENT REACT THEREโ€™S A LOT OF

    INFORMATION OUT THERE
  153. None
  154. #6 DEEP DIVING ON CONCURRENT REACT TRY TO CORRELATE BUSINESS

    METRICS WITH PERFORMANCE
  155. Weโ€™re hiring! ๐Ÿ—บ Mostly inโ€ฆ ๐Ÿ‡บ๐Ÿ‡ธ๐Ÿ‡ฒ๐Ÿ‡ฝ๐Ÿ‡ฆ๐Ÿ‡ท๐Ÿ‡บ๐Ÿ‡พ๐Ÿ‡ช๐Ÿ‡ธ๐Ÿ‡จ๐Ÿ‡ฟ๐Ÿ‡ฎ๐Ÿ‡ฑ๐Ÿ‡ฎ๐Ÿ‡ณ

  156. ๐Ÿค— ๐Ÿ‡ฎ๐Ÿ‡ณ

  157. DEEP DIVING ON CONCURRENT REACT

  158. DEEP DIVING ON CONCURRENT REACT

  159. THATโ€™S ALL, FOLKS! THANKS! QUESTIONS? MATHEUS ALBUQUERQUE