https://github.com/acdlite/react-fiber-architecture
The goal of React Fiber: incremental rendering
- the ability to pause, abort, or reuse work as new updates come in;
- the ability to assign priority to different types of updates;
- and new concurrency primitives.
- React Components, Elements, and Instances - "Component" is often an overloaded term. A firm grasp of these terms is crucial.
- Reconciliation - A high-level description of React's reconciliation algorithm.
- React Basic Theoretical Concepts - A description of the conceptual model of React without implementation burden. Some of this may not make sense on first reading. That's okay, it will make more sense with time.
- React Design Principles - Pay special attention to the section on scheduling. It does a great job of explaining the why of React Fiber.
- reconciliation
- The algorithm React uses to diff one tree with another to determine which parts need to be changed.
- update
- A change in the data used to render a React app. Usually the result of `setState`. Eventually results in a re-render.
The central idea of React's API is to think of updates as if they cause the entire app to re-render.
React has optimizations which create the appearance of whole app re-rendering while maintaining great performance. The bulk of these optimizations are part of a process called reconciliation.
The key points are:
- Different component types are assumed to generate substantially different trees. React will not attempt to diff them, but rather replace the old tree completely.
- Differing of lists is performed using keys. Keys should be "stable, predictable, and unique."
In React, reconciliation and rendering are separate phases.
Fiber reimplements the reconciler. It is not principally concerned with rendering.
The key points are:
- In a UI, it's not necessary for every update to be applied immediately; in fact, doing so can be wasteful, causing frames to drop and degrading the user experience.
- Different types of updates have different priorities — an animation update needs to complete more quickly than, say, an update from a data store.
- A push-based approach requires the app (you, the programmer) to decide how to schedule work. A pull-based approach allows the framework (React) to be smart and make those decisions for you.
Primary goal of Fiber
- pause work and come back to it later.
- assign priority to different types of work.
- reuse previously completed work.
- abort work if it's no longer needed.
A fiber represents a unit of work.
The way computers typically track a program's execution is using the call stack. When a function is executed, a new stack frame is added to the stack. That stack frame represents the work that is performed by that function.
Newer browsers (and React Native) implement APIs that help address this exact problem: requestIdleCallback schedules a low priority function to be called during an idle period, and requestAnimationFrame schedules a high priority function to be called on the next animation frame.
Fiber is reimplementation of the stack, specialized for React components. You can think of a single fiber as a virtual stack frame.
The advantage of reimplementing the stack is that you can keep stack frames in memory and execute them however (and whenever) you want. This is crucial for accomplishing the goals we have for scheduling.
Aside from scheduling, manually dealing with stack frames unlocks the potential for features such as concurrency and error boundaries.
In concrete terms, a fiber is a JavaScript object that contains information about a component, its input, and its output.
A fiber corresponds to a stack frame, but it also corresponds to an instance of a component.
The type of a fiber describes the component that it corresponds to. For composite components, the type is the function or class component itself. For host components (div, span, etc.), the type is a string.