Wewnątrz React Fiber: jednostki pracy, Render vs Commit oraz pasma priorytetowe
Dowiedz się, czym właściwie jest React Fiber, dlaczego stary mechanizm synchronizacji blokował główny wątek oraz jak jednostki pracy, dwie fazy i torowiska umożliwiają równoczesne renderowanie.
"Fiber" to jeden z tych terminów w React, który jest powtarzany znacznie częściej, niż faktycznie zostaje wyjaśniony. Programiści słyszą, że jest to nowy silnik, zamiennik Virtual DOM lub coś związanego z Hooks, ale żaden z tych opisów nie jest do końca prawidłowy. Ten przewodnik buduje tę koncepcję od podstaw: najpierw problem, z którym borykał się React przed wersją 16, potem to, czym jest Fiber, jak renderowanie dzieli się na dwie fazy oraz jak działają planowanie i priorytety. Pod koniec powinieneś być w stanie dokładnie wyjaśnić, czym jest Fiber, rozpoznać powszechne błędne wyobrażenia i zrozumieć, dlaczego takie API jak startTransition od niego zależą.
Fiber w jednym zdaniu
React Fiber to wewnętrzna architektura synchronizacji, która pojawiła się wraz z React 16. Jej zadaniem jest umożliwienie kontrolowanego wykonywania operacji renderowania. Zamiast traktować aktualizację jako jedno, nierozdzielne zadanie, React modeluje tę pracę jako wiele małych jednostek, które może przetwarzać po kolei i sortować według ich ważności.
Najłatwiej zobaczyć tę zmianę, porównując oba podejścia. Przed Fiber aktualizacja przebiegała w linii prostej od początku do końca:
Before Fiber:
Update
↓
Render entire tree
↓
Commit changes
↓
Done
Z Fiber pojawia się dodatkowy etap, na którym praca jest dzielona na części, a te części mogą być uporządkowane, wstrzymane i wznowione, zanim cokolwiek pojawi się na ekranie:
After Fiber:
Update
↓
Break work into units
↓
Process units
↓
Prioritize / pause / resume when appropriate
↓
Commit changes
Ten dodatkowy etap stanowi podstawę niemal wszystkich nowoczesnych funkcji renderowania w React. Aby zrozumieć, dlaczego uzasadniało to przeredagowanie kodu, spójrzmy na to, co istniało wcześniej.
Synchronizator stosu i jego słaby punkt
Wersje Reacta przed 16 używały tego, co zwykle nazywa się Stack Reconciler. Ogólny proces był już znany: zmiana stanu powoduje renderowanie, które jest porównywane z poprzednim wynikiem, a następnie aktualizowany jest DOM.
State Change
↓
Render
↓
Reconciliation
↓
DOM Updates
Problem polegał na tym, że proces porównywania odbywał się synchronicznie. Nazwa pochodzi z faktu, że mechanizm ten przeszukiwał drzewo za pomocą zwykłych rekurencyjnych wywołań funkcji, więc postęp pracy znajdował się bezpośrednio na stosie wywołań JavaScripta. Gdy React rozpoczynał przetwarzanie aktualizacji, nie miał naturalnego sposobu na jej przerwanie w połowie, ponieważ takie działanie oznaczałoby zwrot na poprzednie poziomy stosu i utratę aktualnego stanu. Wyobraźmy sobie umiarkowanie dużą aplikację:
App
│
├── Header
├── Sidebar
├── Dashboard
│ ├── Chart
│ ├── Table
│ └── Statistics
├── Notifications
└── Footer
Jeśli aktualizacja wpłynęła na dużą część tego drzewa, React przeszłoby przez wszystkie dotknięte komponenty w jednej ciągłej sekwencji, od pierwszego do ostatniego, nie zwracając nigdy kontroli:
Start rendering
↓
Component A
↓
Component B
↓
Component C
↓
Component D
↓
Component E
↓
...
↓
Finish
Wynik był w porządku; problemem był czas. React nie mogło przerwać pracy i wznowić jej później, więc wszystko inne musiało czekać.
Dlaczego długi proces renderowania szkodzi użytkownikowi
JavaScript nie ma do dyspozycji własnego wątku głównego. Przeglądarka używa tego samego wątku do obsługi zdarzeń, obliczania układu, rysowania pikseli i tworzenia klatek:
Browser Main Thread
│
├── JavaScript
├── Event Handling
├── Layout
├── Paint
└── Rendering
Gdy skrypt zajmuje wątek przez długi czas, wszystkie te zadania kumulują się za nim w kolejce. Z perspektywy użytkownika łańcuch zdarzeń wygląda w ten sposób:
Click
↓
React starts large update
↓
Main thread remains busy
↓
Browser can't respond quickly
↓
UI feels slow
Kliknięcie jest rejestrowane z opóźnieniem, naciśnięcie klawisza pojawia się po zauważalnej przerwie, a animacja ma problemy z płynnością. W małej aplikacji proces renderowania trwa tak krótko, że nikt tego nie zauważa. Jednak w miarę rozwoju aplikacji i wzrostu liczby interakcji framework musi decydować o kiedy odbywa się renderowanie oraz ile z niego może zostać wykonywanych jednocześnie. To właśnie tę lukę ma za zadanie zamknąć Fiber.
Główna idea: praca w postaci jednostek planowalnych
Model myślowy Fiber można streścić w jednej linijce: renderowanie jest dzielone na zarządzalne jednostki pracy, które React może planować i priorytetyzować.
Zgodnie ze starym modelem polecenie skierowane do mechanizmu synchronizacji polegało w praktyce na jednej komendzie:
"Render this entire tree."
W modelu Fiber React może natomiast analizować poszczególne elementy i zdecydować, które z nich wymagają pierwszej uwagi:
"Here is one piece of work."
"Here is another piece."
"Which work should I process first?"
Zamiast głębokiego wywołania rekurencyjnego, przy użyciu oddzielnych elementów React może zatrzymać się po każdym z nich, sprawdzić, czy są ważniejsze zadania do wykonania, a następnie kontynuować później.
Czym właściwie jest fiber
Fiber to zwykły obiekt JavaScript, który reprezentuje jedną jednostkę pracy w wewnętrznym drzewie React. W praktyce istnieje mniej więcej jeden fiber na komponent lub element biorący udział w procesie synchronizacji. Spójrzmy na to małe drzewo komponentów:
App
│
├── Header
├── Sidebar
└── Content
Koncepcyjnie React utrzymuje strukturę równoległą składającą się z fiber:
Fiber Tree
App Fiber
│
├── Header Fiber
├── Sidebar Fiber
└── Content Fiber
Rzeczywiste obiekty Fiber zawierają o wiele więcej niż tylko nazwę. Zapisują one swoje powiązania z węzłami rodzicowskimi, potomnymi i braćmi, typ oraz tożsamość komponentu, propozycje i stan w oczekiwaniu na zatwierdzenie, a także efekty, które muszą zostać uruchomione po zakończeniu pracy. To właśnie te wyraźne powiązania umożliwiają Reactowi przemieszczanie się po drzewie za pomocą pętli zamiast rekurencji, co z kolei umożliwia zatrzymywanie i kontynuowanie procesu. Jeśli chodzi o całą architekturę, wystarczy pamiętać jedną zasadę: Fiber to jednostka pracy Reacta nad renderowaniem i synchronizacją.
Fiber nie zastępuje Virtual DOM
Często twierdzi się, że Fiber „zastąpił Virtual DOM”. Tak nie jest. Obie te koncepcje odpowiadają na różne pytania.
Virtual DOM to opis tego, jak powinien wyglądać interfejs użytkownika, który React porównuje z poprzednim opisem, aby ustalić, co musi ulec zmianie:
Virtual DOM
↓
"What should the UI look like?"
Fiber to mechanizm, którego używa React do organizacji i wykonywania zadań niezbędnych do osiągnięcia tego celu:
Fiber
↓
"How should React organize and process the work required to get there?"
Pracują razem, ale jeden stanowi reprezentację interfejsu użytkownika, a drugi sposób przetwarzania zadań. Jeśli chcesz dokładniej przyjrzeć się porównaniu, zobacz jak mechanizm Virtual DOM w React decyduje, co aktualizować.
Drzewo fiber podczas aktualizacji
React utrzymuje swoje drzewo fiber przez cały czas trwania aplikacji. Nieco bardziej złożony przykład pokazuje, jak poddrzewo jest w nim umieszczone:
App
│
┌─────────┼─────────┐
↓ ↓ ↓
Header Sidebar Content
│
┌──────┴──────┐
↓ ↓
Chart Table
Gdy zmieniają się propsy lub stan, React wykorzystuje tę strukturę, aby znaleźć gałęzie wymagające działania i pominąć pozostałe.
Czynienie renderowania przerwalnym
Najważniejszą konsekwencją tego projektu jest możliwość wstrzymania procesu renderowania. Rozważmy aktualizację, która składa się z kilku etapów pracy:
Large Update
↓
Work 1
↓
Work 2
↓
Work 3
↓
Work 4
W przypadku synchronicznego mechanizmu synchronizacji wszystkie cztery etapy musiały być wykonywane kolejno. Dzięki Fiber React może przetworzyć kilka z nich, pozwolić przeglądarce na odpowiedź na dane wejściowe lub narysowanie klatki, a następnie kontynuować:
Work 1
↓
Work 2
↓
Pause
↓
Browser gets an opportunity to handle other work
↓
Resume
↓
Work 3
↓
Work 4
To samo w sobie nie jest optymalizacją szybkości; łączna ilość pracy pozostaje taka sama. Praca po prostu nie monopolizuje już wątku, co daje Reactowi możliwość jej zaplanowania.
Dwie fazy: ustalenie zmian, a następnie ich zastosowanie
Współczesny React nie traktuje aktualizacji jako jednego kroku od renderowania do DOM:
Render → DOM
Zamiast tego każda aktualizacja przechodzi przez dwie odrębne fazy:
React Update
│
↓
Render Phase
│
↓
Commit Phase
│
↓
DOM
Faza renderowania oblicza następny interfejs użytkownika
W fazie renderowania React odpowiada na pytanie, jak powinien teraz wyglądać interfejs użytkownika. Konkretnie:
- wykonuje funkcje komponentów i przetwarza czekające aktualizacje
- buduje lub synchronizuje drzewo fiber
- określa, co różni się od obecnego drzewa
- zbiera listę zmian, które należy zastosować
W formie diagramu wprowadza się poprzednie drzewo oraz nowe aktualizacje, a w wyniku otrzymuje się opis niezbędnych działań:
Previous Tree
+
New Updates
↓
Reconciliation
↓
New Work
Ponieważ w tej fazie nic nie wpływa na DOM, może ona zostać przerwana w nowoczesnym React. React może obliczyć dużą część następnego drzewa w tle, a nikt nie widzi żadnego pośredniego stanu. To również tłumaczy, dlaczego React oczekuje, że renderowanie będzie wolne od efektów ubocznych: podczas równoczesnego renderowania komponent może zostać wyrenderowany więcej niż raz, zanim jego wynik zostanie zapisany, a w trybie Strict Mode logika renderowania jest celowo wywoływana dwukrotnie, aby ujawnić kod, który nie działa przy takim założeniu.
Faza zapisu stosuje wynik
Gdy zmiany są już znane, React je zapisuje:
Render Phase
↓
Changes determined
↓
Commit Phase
↓
DOM updated
To właśnie w fazie zapisu następują rzeczywiste modyfikacje: wstawiane, aktualizowane lub usuwane są węzły DOM, przypisywane są referencje, a uruchamiane są efekty układu. Praktyczny sposób na oddzielenie tych dwóch faz:
Render Phase
"Let's figure out what needs to change."
Commit Phase
"Now apply those changes."
Dlaczego fazy zapisu nie można wstrzymać
Jeśli pauzowanie jest tak przydatne, dlaczego nie robić tego wszędzie? Ponieważ ekran musi pozostać spójny. Wyobraź sobie, że React przestanie pisać do DOM w połowie procesu:
Update A
↓
DOM partially changed
↓
Pause
↓
Update B
Użytkownik zobaczyłby mieszankę starego i nowego interfejsu, która nigdy logicznie nie istniała. Dlatego React oddziela różne aspekty: przetwarzanie zmian może zostać przerwane, rozpoczęte od nowa lub odrzucone, ale commit aplikuje gotowy wynik jednorazowo. Ta granica jest kluczowa dla zrozumienia nowoczesnego Reacta.
Szczegółowe planowanie: nie wszystkie aktualizacje są równe
Gdy praca jest podzielona na jednostki, React może zacząć określać, która praca jest najważniejsza. Niektóre aktualizacje są wyraźnie bardziej pilne niż inne. W odpowiedzi na to:
User clicks a button
dla użytkownika w danym momencie jest ważniejsze niż to:
Rendering a large list somewhere else
W ten sam sposób, to:
Typing in an input
Musi to wyglądać na natychmiastowe. Intensywne aktualizacje odbywające się w innych częściach strony nie powinny powodować opóźnień pomiędzy ruchem klawiatury a wyświetlanymi znakami. Fiber zapewnia strukturę, która pozwala Reactowi analizować takie różnice i odpowiednio uporządkowywać prace.
Lane’y: jak React określa priorytet
Wewnętrznie nowoczesne tagi React obsługują aktualizacje za pomocą lane’ów, które kodują ich priorytet. Kod aplikacji prawie nigdy nie pracuje bezpośrednio z lane’ami; React wykorzystuje je do decydowania, które aktualizacje oczekujące należy przetworzyć podczas danej renderizacji, a które mogą poczekać. Uproszczone przedstawienie:
Updates
│
┌───────────┼───────────┐
↓ ↓ ↓
Urgent Normal Deferred
│ │ │
↓ ↓ ↓
Process Process Process
sooner normally later
Pomaga oddzielać trzy powiązane terminy, gdy pojawiają się razem:
Fiber
↓
Represents work
Scheduler
↓
Helps coordinate when work should happen
Lanes
↓
Represent priority of updates
Fiber opisuje pracę do wykonania, planer decyduje o jej czasie uruchomienia, a kanały wskazują, na jak pilną jest każda aktualizacja. Konkretna implementacja tych elementów zmieniała się pomiędzy wersjami React, więc należy traktować to jako model koncepcyjny, a nie opis bieżącego kodu źródłowego.
Stare kontra nowe, krok po kroku
Zanim pojawił się Fiber, proces synchronizacji odbywał się synchronicznie i na podstawie stosu, a gdy już się rozpoczynał, po prostu trwał bez przerwy:
Update
↓
Reconcile
↓
Continue
↓
Continue
↓
Continue
↓
Finish
Było niewiele możliwości przerwania tej pracy lub faworyzowania jednej aktualizacji kosztem innej.
Architektura Fiber wprowadza decyzje planistyczne do procesu przetwarzania danych:
Update
↓
Create / schedule work
↓
Process Fiber units
↓
Prioritize
↓
Pause / resume / restart when appropriate
↓
Complete render
↓
Commit
Gdy umieści się oba te procesy obok siebie, różnica staje się oczywista:
BEFORE FIBER:
Component Tree
↓
Synchronous Reconciliation
↓
Finish Everything
↓
Commit
AFTER FIBER:
Component Tree
↓
Fiber Tree
↓
Units of Work
↓
Prioritize / Schedule
↓
Render
↓
Commit
Celem nie było przyspieszenie React, lecz uzyskanie kontroli nad tym, w jaki sposób i kiedy odbywa się renderowanie.
Powszechne błędne przekonania
Fiber nie dodaje wątków
Fiber nie dzieli React na kilka wątków:
React
├── Thread 1
├── Thread 2
└── Thread 3
Język JavaScript używany w React nadal działa na głównym wątku w przeglądarce. Fiber to forma współpracy przy planowaniu: React dobrowolnie ustępuje miejsca innym zadaniom, aby te mogły zostać wykonywane. Różni się to fundamentalnie od Web Workers, które rzeczywiście wykonują kod na oddzielnym wątku.
Konkurencyjność nie oznacza jednoczesności
Fiber umożliwia konkurencyjne renderowanie, ale słowo „konkurencyjny” łatwo jest błędnie zinterpretować. Nie oznacza to, że React renderuje wszystko w tym samym momencie. Oznacza to, że React może przygotować aktualizację bez blokowania aplikacji przez cały czas trwania długiego procesu renderowania. Typowa sekwencja:
Low-priority update
↓
React starts rendering
↓
Higher-priority update arrives
↓
React can prioritize the important work
↓
Continue / restart lower-priority work
Renderyzację o niskim priorytecie można odłożyć, gdy pojawi się coś pilniejszego, a następnie kontynuować ją lub rozpocząć od nowa. To właśnie ten mechanizm umożliwia płynniejsze interakcje w nowoczesnym React. Jak to wygląda w środowisku frameworka, omawia artykuł na temat częściowego przedrenderowania i równoczesnego renderowania, skupiający się na podejściu Next.js.
Fiber to nie „jeden komponent naraz”
Kuszące jest również wyobrażenie, że Fiber renderuje dokładnie jeden komponent, potem następny i tak dalej:
Component 1
Component 2
Component 3
To zbyt uproszczone. Proces przeglądania, grupowania i planowania w React jest znacznie bardziej złożony niż w przypadku prostego listy; Fiber oferuje model pracy o znacznie większej drobności niż stary, rekurencyjny podejście.
Przejścia w praktyce
Przejścia to miejsca, w których planowanie działania Fiber staje się widoczne w kodzie aplikacji. Weźmy pole wyszukiwania, do którego użytkownik właśnie wpisał tekst:
User types: "rea"
To naciśnięcie klawisza uruchamia dwa różne rodzaje działań:
1. Update the input immediately
2. Update a huge search result list
Uaktualnianie wprowadzonego tekstu jest tym, co obserwuje użytkownik; ponowne generowanie długiej listy wyników może być kosztowne. React umożliwia oznaczenie drugiego rodzaju działań jako nieważnych poprzez umieszczenie aktualizacji stanu wewnątrz startTransition:
startTransition(() => {
setSearchResults(results);
});
Wpisane znaki są traktowane jako pilna aktualizacja, dzięki czemu pole pozostaje responsywne:
User Input
↓
Urgent Update
↓
Keep UI responsive
Lista wyników jest traktowana jako przejście, które React może wyświetlić z niższym priorytetem i przerwać, jeśli użytkownik będzie dalej pisał:
Search Results
↓
Transition
↓
Can be handled with lower priority
Dwie praktyczne uwagi. Po pierwsze, przejścia nie sprawiają, że kosztowne operacje stają się tańsze; jedynie zapobiegają temu, by blokowały pilne aktualizacje, więc powolna lista może nadal skorzystać z memoizacji lub wirtualizacji. Po drugie, stan samego wprowadzanych danych powinien pozostać poza procesem przejścia, w przeciwnym razie samo pisanie staje się odroczalne, a pole wydaje się wolne w działaniu. Całe to planowanie nie byłoby możliwe bez fazy renderowania podlegającej przerwaniu, którą zapewnia Fiber.
Dlaczego React potrzebował nowych podstaw
Zanim pojawił się Fiber, React już posiadał większość elementów, które z nim kojarzy się:
- Wirtualny DOM
- Synchronizację stanu
- Model komponentów
- Skuteczne aktualizacje DOM-u
Ponowny projekt dotyczył przyszłości, a nie naprawiania czegoś uszkodzonego. Aplikacje rozwijały się jednocześnie w kilku kierunkach:
Larger
+
More interactive
+
More data-driven
+
More complex
Taki wzrost oznaczał, że React musiał brać pod uwagę coś więcej niż tylko to, co się zmieniło. Musiał również odpowiadać na pytania takie jak to, kiedy dana operacja powinna zostać wykonaana, jak ważna jest aktualizacja, czy można przerwać pracę, czy inna aktualizacja powinna przejść przed nią w kolejce, oraz jak uniknąć blokowania interakcji, które są najważniejsze dla użytkowników. Fiber to architektura, która umożliwia udzielenie odpowiedzi na te pytania.
Szczegóły scenariusza
Rozważmy panel analityczny z kilkoma obciążającymi elementami:
Dashboard
│
├── Navigation
├── Filters
├── Revenue Chart
├── User Chart
├── Large Data Table
└── Notifications
Gdy użytkownik zmienia filtr, prosta implementacja może ponownie renderować wykresy i dużą tabelę w jednej operacji, przez co kontrolka filtru będzie reagować powoli. W architekturze Fiber ta sama interakcja przechodzi przez uprzywilejowane operacje:
User changes filter
↓
Update begins
↓
React performs reconciliation
↓
Work is represented through Fiber
↓
Updates can be prioritized
↓
Rendering completes
↓
Commit changes
Wykresy i tabele nadal muszą zostać przeliczone. Poprawia się natomiast responsywność, ponieważ React zajmuje się tym zadaniem.
Fiber w porównaniu z sąsiednimi koncepcjami
Fiber i Virtual DOM
Virtual DOM to reprezentacja interfejsu użytkownika, której React używa do określenia tego, co wymaga zmiany:
UI State
↓
Virtual Representation
Fiber to wewnętrzna architektura i struktura danych, za pomocą której React reprezentuje i przetwarza zadania renderowania:
Component / Element
↓
Fiber
↓
Reconciliation + Scheduling
Razem tworzą one system renderowania Reacta:
Virtual DOM
+
Fiber Architecture
↓
React Rendering System
Powiązane, ale nie zamienne.
Fiber i Web Workers
Rozwiązują one zupełnie różne problemy. Fiber dotyczy:
Rendering
Reconciliation
Scheduling
Prioritization
Z kolei Web Worker służy do:
Running JavaScript
outside the main UI execution context
Jego struktura wygląda w ten sposób, przy czym obciążone obliczenia są przenoszone z wątku, który zarządza interfejsem użytkownika:
Main Thread
│
├── UI
├── React
│
↓
Web Worker
│
↓
Heavy computation
Fibry nigdy nie przenoszą procesu renderowania w React do workera. Jeśli masz obciążone CPU zadania, które nie są związane z renderowaniem, takie jak analiza tekstu lub obliczenia liczbowe, worker nadal jest odpowiednim narzędziem; artykuł na temat dedykowanych, współdzielonych i workerów usługowych omawia te opcje.
Co to oznacza dla twojego kodu
W codziennej pracy nigdy nie manipulujesz bezpośrednio fibrami. Tworzysz komponenty:
function App() {
return <Dashboard />;
}
i uruchamiasz aktualizacje:
setState(newValue);
React w tle przekształca je na zadania dla fibr. Twój kod znajduje się na szczycie łańcucha przetwarzania, a o niższych warstwach rzadko musisz myśleć:
Your React Code
↓
React APIs
↓
Fiber Architecture
↓
Reconciliation
↓
Scheduling / Prioritization
↓
Commit
↓
DOM
Nigdy nie tworzysz ręcznie węzłów Fiber. Potrzebny jest określony model myślowy: utrzymuj logikę renderowania w stanie czystym, umieszczaj efekty uboczne w funkcjach effects lub handlers, a do kosztownych, nieważnych aktualizacji używaj przejść.
Najkrótszy możliwy streszczenie
Stary mechanizm reconciler stosował prostą zasadę:
"Start rendering → keep going → finish."
Fiber stosuje inną zasadę:
"Break rendering into work → decide how to schedule it
→ complete the render → commit the result."
To różnica stanowi w skrócie całą zmianę architektoniczną.
Zakończenie
Mechanizm reconciler na bazie stosu dobrze służył Reactowi przez lata. Fiber rozwiązywał problemy aplikacji, które przewyższały jego możliwości. Ewolucja przebiega od ograniczonej kontroli:
Old React
↓
Synchronous Stack Reconciler
↓
Limited control over rendering work
do modelu, w którym praca jest wyraźna, możliwa do planowania i priorytetyzacji:
React Fiber
↓
Fiber Tree + Units of Work
↓
More flexible reconciliation
↓
Scheduling + Prioritization
↓
Concurrent Rendering Capabilities
Gdy ktoś pyta, czym jest React Fiber, określenie „nowy silnik renderowania” nie oddaje jego prawdziwego znaczenia. Dokładniejszą odpowiedzią jest to, że Fiber to wewnętrzna architektura synchronizacji React, która modeluje proces renderowania jako jednostki pracy, dzięki czemu React może planować, ustalać priorytety, przerywać i wznowiać te operacje w odpowiednich momentach.
Główne wnioski
- Fiber pojawił się w React 16 i zastąpił rekurencyjny, synchroniczny Stack Reconciler.
- Fiber to obiekt reprezentujący jedną jednostkę pracy renderowania, połączona w drzewo, które React może przemierzać i zawieszać.
- Faza renderowania oblicza zmiany i może być przerwana; faza zatwierdzenia aplikuje je w jednym, nieprzerwanym kroku.
- Lanes oraz planer wykorzystują strukturę Fiber, aby nadawać priorytet pilnym aktualizacjom przed tymi odroczonymi.
Literatura pokrewna
- Scheduler w React i pętla zdarzeń: Kto naprawdę decyduje, kiedy wykonywane są operacje — Dowiedz się, jak współpracujący Scheduler w React działa wewnątrz pętli zdarzeń JavaScript, dlaczego przejścia mogą być wstrzykiwane oraz dlaczego żaden scheduler nie może uratować zablokowanego wątku.
- Zrozumienie React Lanes: Jak bitmaski kodują priorytetaktualizacji — Dowiedz się, jak React używa bitmasek do kodowania kilku priorytetówaktualizacji w jeden liczbę całkowitą, oraz dlaczego operacje bitowe zastępują proste flagi logiczne przy planowaniu.