A Deep Dive Into Concurrent React by Matheus Albuquerque

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 of the concurrent React features, understanding their rationales, and how they work under the hood.

1. DEEP DIVING ON CONCURRENT REACT 👨💻 @medallia 🧑🏫 @techlabs 🐦 @ythecombinator ↑ ALL THE LINKS! 🤓 ⚡ Perf GDE

2. #DISCLAIMER 😌 This is a deep dive for those who are interested in API discussions . You don’t need to know all of that to be productive with React.

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

4. The Main Thread DEEP DIVING ON CONCURRENT REACT

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

6. — AKAMAI AND CHROME RESEARCHµ 2017

7. #QUESTION 🤔 How to avoid blocking the main thread?

8. A B C D

9. PARALLELISM CONCURRENCY SCHEDULING

10. PARALLELISM CONCURRENCY SCHEDULING

11. ↝ DATA EXCHANGE IS THROUGH MESSAGE-PASSING ↝ NO ACCESS TO ANY VARIABLES/CODE FROM THE PAGE THAT CREATED THEM OR VICE VERSA ↝ NO ACCESS TO THE DOM µ MAKING UI UPDATES FROM A WORKER BARELY IMPOSSIBLE ↝ TWO MODELS: ACTORS & SHARED MEMORY

12. 🎭 ACTORS ↝ EACH ACTOR FULLY OWNS THE DATA IT IS OPERATING ON ↝ ACTORS CAN ONLY SEND/REACT TO MESSAGES ↝ THE MAIN THREAD IS ACTOR THAT OWNS THE DOM/UI ↝ postMessage HAS NO BUILT-IN UNDERSTANDING OF REQUEST AND RESPONSE ↝ BALANCE: MOVING CODE TO A WORKER VS COMMUNICATION OVERHEAD / WORKER BEING BUSY ↝ ONE DEDICATED TYPE: SharedArrayBuffer ↝ IF SENT VIA postMessage µ THE OTHER END GETS A HANDLE TO THE EXACT SAME MEMORY CHUNK ↝ MOST OF THE WEB APIS ARE BUILT NO CONCURRENT ACCESS TO OBJECTS ↝ YOU BUILD YOUR OWN CONCURRENT DATA STRUCTURES ↝ NO DIRECT WAY OF WORKING ON FAMILIAR OBJECTS/ARRAYS ; JUST A SERIES OF BYTES 🔗 SHARED MEMORY

13. 🎭 ACTORS ↝ EACH ACTOR FULLY OWNS THE DATA IT IS OPERATING ON ↝ ACTORS CAN ONLY SEND/REACT TO MESSAGES ↝ THE MAIN THREAD IS ACTOR THAT OWNS THE DOM/UI ↝ postMessage HAS NO BUILT-IN UNDERSTANDING OF REQUEST AND RESPONSE ↝ BALANCE: MOVING CODE TO A WORKER VS COMMUNICATION OVERHEAD / WORKER BEING BUSY ↝ ONE DEDICATED TYPE: SharedArrayBuffer ↝ IF SENT VIA postMessage µ THE OTHER END GETS A HANDLE TO THE EXACT SAME MEMORY CHUNK ↝ MOST OF THE WEB APIS ARE BUILT NO CONCURRENT ACCESS TO OBJECTS ↝ YOU BUILD YOUR OWN CONCURRENT DATA STRUCTURES ↝ NO DIRECT WAY OF WORKING ON FAMILIAR OBJECTS/ARRAYS ; JUST A SERIES OF BYTES 🔗 SHARED MEMORY

14. ↝ THE BEST EXPERIENCE FOR SHARED-MEMORY MODEL ↝ DOESN’T OFFER THE "COMFORT" OF JAVASCRIPT ↝ FASTER WHEN YOU STAY WITHIN WASM ↝ JAVASCRIPT IS OFTEN FASTER AT DOM AND HIGH- LEVEL UI LIBRARIES CAN BE MORE PERFORMANT THAN LOW-LEVEL WASM IMPLEMENTATIONS

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

16. ↝ GOOD FOR DATA PROCESSING AND CRUNCHING NUMBERS ↝ HARD TO USE FOR UI-RELATED STUFF ↝ PERHAPS HARDER THAN ADJUSTING WORK FOR A SCHEDULER

17. PARALLELISM CONCURRENCY SCHEDULING

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

19. Scheduling in React DEEP DIVING ON CONCURRENT REACT

20. ↝ 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

21. ↓ ORIGINAL RENDER TASK USER INPUT → ↑ HIGHER PRIORITY RENDER TASK ↓ RESUME ORIGINAL RENDER TASK

22. ↝ 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

23. #QUESTION 🤔 How do we benefit from these in our everyday projects ?

24. Scheduling in React [ for the rest of us ] DEEP DIVING ON CONCURRENT REACT

25. 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!

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

27. 😔 NON-PRACTICAL… ↝ FINDING PRIMES ↝ CRACKING PASSWORDS ↝ SIERPINSKI TRIANGLE 😊 PRACTICAL… ↝ RENDERING MANY DATA-POINTS ↝ RENDERING ON A <canvas> ↝ PROCESSING DATA

28. 😊 PRACTICAL… ↝ RENDERING MANY DATA-POINTS ↝ RENDERING ON A <canvas> ↝ PROCESSING DATA 😔 NON-PRACTICAL… ↝ FINDING PRIMES ↝ CRACKING PASSWORDS ↝ SIERPINSKI TRIANGLE

29. const DailyVisitors = () 3 { const [data, setData] = useState(initialData); useEffect(() 3 { setData(initialData); }, []); const onChange = (newData) 3 { setData(newData); }; return ( < Dashboard data ={ data } initialData ={ initialData } onChange ={ onChange } /> ); }; export default DailyVisitors;

30. const DailyVisitors = () 3 { const [data, setData] = useState(initialData); const [, startTransition] = useTransition(); useEffect(() 3 { setData(initialData); }, []); const onChange = (newData) 3 { startTransition(() 3 { setData(newData); }); }; return ( <Dashboard data={data} initialData={initialData} onChange={onChange} /> ); }; export default DailyVisitors;

31. ↝ ˜ 100K + POINTS PLOTTED ↝ SUPPORT FOR SEARCHING AND FILTERING ↝ USED WORKERS + REDUX-SAGA UTILITIES + DEBOUNCING ↝ COULD'VE USED TRANSITIONS

32. ↝ THOUSANDS OF REAL-TIME PLAYERS MESSAGING ↝ SUPPORT FOR SEARCHING AND FILTERING ↝ USED VIRTUALIZATION AND MEMOIZATION ↝ COULD'VE USED TRANSITIONS

33. #2 TACKLING WASTED RENDERS DEEP DIVING ON CONCURRENT REACT

34. 3 () 3 void , function useSyncExternalStore< Snapshot >( subscribe: (onStoreChange: () 3 void ) getSnapshot: () 3 Snapshot, getServerSnapshot?: () 3 Snapshot ): Snapshot;

35. DEEP DIVING ON CONCURRENT REACT

36. #QUESTION 🤔 How do we benefit from these in our everyday projects ?

37. function Pathname() { const { pathname } = useLocation(); return <Badge title={pathname} subtitle= "pathname" />; } function Hash() { const { hash } = useLocation(); return <Badge title={hash} subtitle= "hash" />; }

38. const { pathname } = useLocation(); const { hash } = useLocation(); OVER-RETURNING HOOK

39. function Pathname() { const { pathname } = useLocation(); return <Badge title={pathname} subtitle= "pathname" />; } function Hash() { const { hash } = useLocation(); return <Badge title={hash} subtitle= "hash" />; }

40. 3 selector(history)); function useHistorySelector(selector) { const history = useHistory(); return useSyncExternalStore(history.listen, () } function Pathname() { const pathname = useHistorySelector((history) 3 history.location.pathname); return <Badge title={pathname} subtitle="pathname" />; } function Hash() { const hash = useHistorySelector((history) 3 history.location.hash); return <Badge title={hash} subtitle="hash" />; }

41. 3 selector(history)); function useHistorySelector(selector) { const history = useHistory(); return useSyncExternalStore(history.listen, () } function Pathname() { const pathname = useHistorySelector((history) 3 history.location.pathname); return <Badge title={pathname} subtitle="pathname" />; } function Hash() { const hash = useHistorySelector((history) 3 history.location.hash); return <Badge title={hash} subtitle="hash" />; }

42. #3 HYDRATION IMPROVEMENTS DEEP DIVING ON CONCURRENT REACT

43. FETCHING DATA (SERVER) RENDERING HTML (SERVER) LOADING CODE (CLIENT) HYDRATING TIME TO FIRST BYTE FIRST CONTENTFUL PAINT TIME TO INTERACTIVE

44. ↝ 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

45. DEEP DIVING ON CONCURRENT REACT

46. FETCHING DATA (SERVER) RENDERING HTML (SERVER) LOADING CODE (CLIENT) HYDRATING TIME TO FIRST BYTE FIRST CONTENTFUL PAINT TIME TO INTERACTIVE

47. TIME TO FIRST BYTE FIRST CONTENTFUL PAINT TIME TO INTERACTIVE […] FETCHING DATA (SERVER) RENDERING HTML (SERVER) HYDRATING LOADING CODE (CLIENT) […] […] […] […] […] […]

48. ↝ 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

49. ↝ 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

50. DEEP DIVING ON CONCURRENT REACT

51. #4 PROFILER ENHANCEMENTS DEEP DIVING ON CONCURRENT REACT

52. — INTRODUCING A NEW REACT PROFILERµ BY BRIAN VAUGHN

53. — INTRODUCING A NEW REACT PROFILERµ BY BRIAN VAUGHN

54. The Future DEEP DIVING ON CONCURRENT REACT

55. ↝ 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

56. ↝ useInsertionEffect FOR STYLESHEET LIBRARIES ↝ THE <Offscreen> COMPONENT ↝ SERVER COMPONENTS ↝ NATIVE SCHEDULING PRIMITIVES ON THE BROWSER

57. DEEP DIVING ON CONCURRENT REACT

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

59. 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.

60. Closing Notes DEEP DIVING ON CONCURRENT REACT

61. DEEP DIVING ON CONCURRENT REACT

62. #1 DEEP DIVING ON CONCURRENT REACT REACT IS NOT REACTIVEµ BUT IT IS CONCURRENT AND THAT MIGHT BE ENOUGH FOR YOU

63. #2 DEEP DIVING ON CONCURRENT REACT REACT HAS BEEN PUSHING WEB APIS TO THE FUTURE E.G. THE SCHEDULER API

64. #3 DEEP DIVING ON CONCURRENT REACT SCHEDULING DOES NOT NECESSARILY MEAN BETTER PERFORMANCE

65. #3 DEEP DIVING ON CONCURRENT REACT SCHEDULING DOES NOT NECESSARILY MEAN BETTER PERFORMANCE ↝ ↝ ↝ NON-URGENT UPDATES TAKE LONGER CAN’T HELP SOME EXPENSIVE COMPONENTS EXTRA CPU COST

66. #4 DEEP DIVING ON CONCURRENT REACT THERE'S NO SILVER BULLET . IDENTIFY YOUR CORE METRICS.

67. #5 DEEP DIVING ON CONCURRENT REACT THERE’S A LOT OF INFORMATION OUT THERE

68. #6 DEEP DIVING ON CONCURRENT REACT ALWAYS TRY TO CORRELATE BUSINESS METRICS WITH PERFORMANCE