React16源碼解讀:揭秘ReactDOM.render

2021-03-03 前端迷

在上一篇文章中我們通過create-react-app腳手架快速搭建了一個簡單的示例,並基於該示例講解了在類組件中React.Component和React.PureComponent背後的實現原理。同時我們也了解到,通過使用 Babel 預置工具包@babel/preset-react可以將類組件中render方法的返回值和函數定義組件中的返回值轉換成使用React.createElement方法包裝而成的多層嵌套結構,並基於源碼逐行分析了React.createElement方法背後的實現過程和ReactElement構造函數的成員結構,最後根據分析結果總結出了幾道面試中可能會碰到或者自己以前遇到過的面試考點。上篇文章中的內容相對而言還是比較簡單基礎,主要是為本文以及後續的任務調度相關內容打下基礎,幫助我們更好地理解源碼的用意。本文就結合上篇文章的基礎內容,從組件渲染的入口點ReactDOM.render方法開始,一步一步深入源碼,揭秘ReactDOM.render方法背後的實現原理,如有錯誤,還請指出。

源碼中有很多判斷類似__DEV__變量的控制語句,用於區分開發環境和生產環境,筆者在閱讀源碼的過程中不太關心這些內容,就直接略過了,有興趣的小夥伴兒可以自己研究研究。

render VS hydrate

本系列的源碼分析是基於 Reactv16.10.2版本的,為了保證源碼一致還是建議你選擇相同的版本,下載該版本的地址和筆者選擇該版本的具體原因可以在上一篇文章的準備階段小節中查看,這裡就不做過多講解了。項目示例本身也比較簡單,可以按照準備階段的步驟自行使用create-react-app快速將一個簡單的示例搭建起來,然後我們定位到src/index.js文件下,可以看到如下代碼:

import React from 'react';
import ReactDOM from 'react-dom';
import './index.css';
import App from './App';
...
ReactDOM.render(<App />, document.getElementById('root'));
...

該文件即為項目的主入口文件,App組件即為根組件,ReactDOM.render就是我們要開始分析源碼的入口點。我們通過以下路徑可以找到ReactDOM對象的完整代碼:

packages -> react-dom -> src -> client -> ReactDOM.js

然後我們將代碼定位到第632行,可以看到ReactDOM對象包含了很多我們可能使用過的方法,例如render、createPortal、findDOMNode,hydrate和unmountComponentAtNode等。本文中我們暫且只關心render方法,但為了方便對比,也可以簡單看下hydrate方法:

const ReactDOM: Object = {
...
/**
* 服務端渲染
* @param element 表示一個ReactNode,可以是一個ReactElement對象
* @param container 需要將組件掛載到頁面中的DOM容器
* @param callback 渲染完成後需要執行的回調函數
*/
hydrate(element: React$Node, container: DOMContainer, callback: ?Function) {
invariant(
isValidContainer(container),
'Target container is not a DOM element.',
);
...
// TODO: throw or warn if we couldn't hydrate?
// 注意第一個參數為null,第四個參數為true
return legacyRenderSubtreeIntoContainer(
null,
element,
container,
true,
callback,
);
},

/**
* 客戶端渲染
* @param element 表示一個ReactElement對象
* @param container 需要將組件掛載到頁面中的DOM容器
* @param callback 渲染完成後需要執行的回調函數
*/
render(
element: React$Element<any>,
container: DOMContainer,
callback: ?Function,
) {
invariant(
isValidContainer(container),
'Target container is not a DOM element.',
);
...
// 注意第一個參數為null,第四個參數為false
return legacyRenderSubtreeIntoContainer(
null,
element,
container,
false,
callback,
);
},
...
};

發現沒,render方法的第一個參數就是我們在上篇文章中講過的ReactElement對象,所以說上篇文章的內容就是為了在這裡打下基礎的,便於我們對參數的理解。事實上,在源碼中幾乎所有方法參數中的element欄位均可以傳入一個ReactElement實例,這個實例就是通過 Babel 編譯器在編譯過程中使用React.createElement方法得到的。接下來在render方法中調用legacyRenderSubtreeIntoContainer來正式進入渲染流程,不過這裡需要留意一下的是,render方法和hydrate方法在執行legacyRenderSubtreeIntoContainer時,第一個參數的值均為null,第四個參數的值恰好相反。

然後將代碼定位到第570行,進入legacyRenderSubtreeIntoContainer方法的具體實現:

/**
* 開始構建FiberRoot和RootFiber,之後開始執行更新任務
* @param parentComponent 父組件,可以把它當成null值來處理
* @param children ReactDOM.render()或者ReactDOM.hydrate()中的第一個參數,可以理解為根組件
* @param container ReactDOM.render()或者ReactDOM.hydrate()中的第二個參數,組件需要掛載的DOM容器
* @param forceHydrate 表示是否融合,用於區分客戶端渲染和服務端渲染,render方法傳false,hydrate方法傳true
* @param callback ReactDOM.render()或者ReactDOM.hydrate()中的第三個參數,組件渲染完成後需要執行的回調函數
* @returns {*}
*/
function legacyRenderSubtreeIntoContainer(
parentComponent: ?React$Component<any, any>,
children: ReactNodeList,
container: DOMContainer,
forceHydrate: boolean,
callback: ?Function,
) {
...
// TODO: Without `any` type, Flow says "Property cannot be accessed on any
// member of intersection type." Whyyyyyy.
// 在第一次執行的時候,container上是肯定沒有_reactRootContainer屬性的
// 所以第一次執行時,root肯定為undefined
let root: _ReactSyncRoot = (container._reactRootContainer: any);
let fiberRoot;
if (!root) {
// Initial mount
// 首次掛載,進入當前流程控制中,container._reactRootContainer指向一個ReactSyncRoot實例
root = container._reactRootContainer = legacyCreateRootFromDOMContainer(
container,
forceHydrate,
);
// root表示一個ReactSyncRoot實例,實例中有一個_internalRoot方法指向一個fiberRoot實例
fiberRoot = root._internalRoot;
// callback表示ReactDOM.render()或者ReactDOM.hydrate()中的第三個參數
// 重寫callback,通過fiberRoot去找到其對應的rootFiber,然後將rootFiber的第一個child的stateNode作為callback中的this指向
// 一般情況下我們很少去寫第三個參數,所以可以不必關心這裡的內容
if (typeof callback === 'function') {
const originalCallback = callback;
callback = function() {
const instance = getPublicRootInstance(fiberRoot);
originalCallback.call(instance);
};
}
// Initial mount should not be batched.
// 對於首次掛載來說,更新操作不應該是批量的,所以會先執行unbatchedUpdates方法
// 該方法中會將executionContext(執行上下文)切換成LegacyUnbatchedContext(非批量上下文)
// 切換上下文之後再調用updateContainer執行更新操作
// 執行完updateContainer之後再將executionContext恢復到之前的狀態
unbatchedUpdates(() => {
updateContainer(children, fiberRoot, parentComponent, callback);
});
} else {
// 不是首次掛載,即container._reactRootContainer上已經存在一個ReactSyncRoot實例
fiberRoot = root._internalRoot;
// 下面的控制語句和上面的邏輯保持一致
if (typeof callback === 'function') {
const originalCallback = callback;
callback = function() {
const instance = getPublicRootInstance(fiberRoot);
originalCallback.call(instance);
};
}
// Update
// 對於非首次掛載來說,是不需要再調用unbatchedUpdates方法的
// 即不再需要將executionContext(執行上下文)切換成LegacyUnbatchedContext(非批量上下文)
// 而是直接調用updateContainer執行更新操作
updateContainer(children, fiberRoot, parentComponent, callback);
}
return getPublicRootInstance(fiberRoot);
}

上面代碼的內容稍微有些多,咋一看可能不太好理解,我們暫且可以不用著急看完整個函數內容。試想當我們第一次啟動運行項目的時候,也就是第一次執行ReactDOM.render方法的時候,這時去獲取container._reactRootContainer肯定是沒有值的,所以我們先關心第一個if語句中的內容:

if (!root) {
// Initial mount
// 首次掛載,進入當前流程控制中,container._reactRootContainer指向一個ReactSyncRoot實例
root = container._reactRootContainer = legacyCreateRootFromDOMContainer(
container,
forceHydrate,
);
...
}

這裡通過調用legacyCreateRootFromDOMContainer方法將其返回值賦值給container._reactRootContainer,我們將代碼定位到同文件下的第517行,去看看legacyCreateRootFromDOMContainer的具體實現:

/**
* 創建並返回一個ReactSyncRoot實例
* @param container ReactDOM.render()或者ReactDOM.hydrate()中的第二個參數,組件需要掛載的DOM容器
* @param forceHydrate 是否需要強制融合,render方法傳false,hydrate方法傳true
* @returns {ReactSyncRoot}
*/
function legacyCreateRootFromDOMContainer(
container: DOMContainer,
forceHydrate: boolean,
): _ReactSyncRoot {
// 判斷是否需要融合
const shouldHydrate =
forceHydrate || shouldHydrateDueToLegacyHeuristic(container);
// First clear any existing content.
// 針對客戶端渲染的情況,需要將container容器中的所有元素移除
if (!shouldHydrate) {
let warned = false;
let rootSibling;
// 循環遍歷每個子節點進行刪除
while ((rootSibling = container.lastChild)) {
...
container.removeChild(rootSibling);
}
}
...
// Legacy roots are not batched.
// 返回一個ReactSyncRoot實例
// 該實例具有一個_internalRoot屬性指向fiberRoot
return new ReactSyncRoot(
container,
LegacyRoot,
shouldHydrate
? {
hydrate: true,
}
: undefined,
);
}

/**
* 根據nodeType和attribute判斷是否需要融合
* @param container DOM容器
* @returns {boolean}
*/
function shouldHydrateDueToLegacyHeuristic(container) {
const rootElement = getReactRootElementInContainer(container);
return !!(
rootElement &&
rootElement.nodeType === ELEMENT_NODE &&
rootElement.hasAttribute(ROOT_ATTRIBUTE_NAME)
);
}

/**
* 根據container來獲取DOM容器中的第一個子節點
* @param container DOM容器
* @returns {*}
*/
function getReactRootElementInContainer(container: any) {
if (!container) {
return null;
}

if (container.nodeType === DOCUMENT_NODE) {
return container.documentElement;
} else {
return container.firstChild;
}
}

其中在shouldHydrateDueToLegacyHeuristic方法中,首先根據container來獲取 DOM 容器中的第一個子節點,獲取該子節點的目的在於通過節點的nodeType和是否具有ROOT_ATTRIBUTE_NAME屬性來區分是客戶端渲染還是服務端渲染,ROOT_ATTRIBUTE_NAME位於packages/react-dom/src/shared/DOMProperty.js文件中,表示data-reactroot屬性。我們知道,在服務端渲染中有別於客戶端渲染的是,node服務會在後臺先根據匹配到的路由生成完整的HTML字符串,然後再將HTML字符串發送到瀏覽器端,最終生成的HTML結構簡化後如下:

<body>
<div id="root">
<div data-reactroot=""></div>
</div>
</body>

在客戶端渲染中是沒有data-reactroot屬性的,因此就可以區分出客戶端渲染和服務端渲染。在 React 中的nodeType主要包含了五種,其對應的值和W3C中的nodeType標準是保持一致的,位於與DOMProperty.js同級的HTMLNodeType.js文件中:

// 代表元素節點
export const ELEMENT_NODE = 1;
// 代表文本節點
export const TEXT_NODE = 3;
// 代表注釋節點
export const COMMENT_NODE = 8;
// 代表整個文檔,即document
export const DOCUMENT_NODE = 9;
// 代表文檔片段節點
export const DOCUMENT_FRAGMENT_NODE = 11;

經過以上分析,現在我們就可以很容易地區分出客戶端渲染和服務端渲染,並且在面試中如果被問到兩種渲染模式的區別,我們就可以很輕鬆地在源碼級別上說出兩者的實現差異,讓面試官眼前一亮。怎麼樣,到目前為止,其實還是覺得挺簡單的吧?

FiberRoot VS RootFiber

在這一小節中,我們將嘗試去理解兩個比較容易混淆的概念:FiberRoot和RootFiber。這兩個概念在 React 的整個任務調度過程中起著關鍵性的作用,如果不理解這兩個概念,後續的任務調度過程就是空談,所以這裡也是我們必須要去理解的部分。接下來接著上一小節的內容,繼續分析legacyCreateRootFromDOMContainer方法中的剩餘內容,在函數體的結尾返回了一個ReactSyncRoot實例,我們重新回到ReactDOM.js文件可以很容易找到ReactSyncRoot構造函數的具體內容:

/**
* ReactSyncRoot構造函數
* @param container DOM容器
* @param tag fiberRoot節點的標記(LegacyRoot、BatchedRoot、ConcurrentRoot)
* @param options 配置信息,只有在hydrate時才有值,否則為undefined
* @constructor
*/
function ReactSyncRoot(
container: DOMContainer,
tag: RootTag,
options: void | RootOptions,
) {
this._internalRoot = createRootImpl(container, tag, options);
}

/**
* 創建並返回一個fiberRoot
* @param container DOM容器
* @param tag fiberRoot節點的標記(LegacyRoot、BatchedRoot、ConcurrentRoot)
* @param options 配置信息,只有在hydrate時才有值,否則為undefined
* @returns {*}
*/
function createRootImpl(
container: DOMContainer,
tag: RootTag,
options: void | RootOptions,
) {
// Tag is either LegacyRoot or Concurrent Root
// 判斷是否是hydrate模式
const hydrate = options != null && options.hydrate === true;
const hydrationCallbacks =
(options != null && options.hydrationOptions) || null;

// 創建一個fiberRoot
const root = createContainer(container, tag, hydrate, hydrationCallbacks);
// 給container附加一個內部屬性用於指向fiberRoot的current屬性對應的rootFiber節點
markContainerAsRoot(root.current, container);
if (hydrate && tag !== LegacyRoot) {
const doc =
container.nodeType === DOCUMENT_NODE
? container
: container.ownerDocument;
eagerlyTrapReplayableEvents(doc);
}
return root;
}

從上述源碼中,我們可以看到createRootImpl方法通過調用createContainer方法來創建一個fiberRoot實例,並將該實例返回並賦值到ReactSyncRoot構造函數的內部成員_internalRoot屬性上。我們繼續深入createContainer方法去探究一下fiberRoot完整的創建過程,該方法被抽取到與react-dom包同級的另一個相關的依賴包react-reconciler包中,然後定位到react-reconciler/src/ReactFiberReconciler.js的第299行:

/**
* 內部調用createFiberRoot方法返回一個fiberRoot實例
* @param containerInfo DOM容器
* @param tag fiberRoot節點的標記(LegacyRoot、BatchedRoot、ConcurrentRoot)
* @param hydrate 判斷是否是hydrate模式
* @param hydrationCallbacks 只有在hydrate模式時才可能有值,該對象包含兩個可選的方法:onHydrated和onDeleted
* @returns {FiberRoot}
*/
export function createContainer(
containerInfo: Container,
tag: RootTag,
hydrate: boolean,
hydrationCallbacks: null | SuspenseHydrationCallbacks,
): OpaqueRoot {
return createFiberRoot(containerInfo, tag, hydrate, hydrationCallbacks);
}

/**
* 創建fiberRoot和rootFiber並相互引用
* @param containerInfo DOM容器
* @param tag fiberRoot節點的標記(LegacyRoot、BatchedRoot、ConcurrentRoot)
* @param hydrate 判斷是否是hydrate模式
* @param hydrationCallbacks 只有在hydrate模式時才可能有值,該對象包含兩個可選的方法:onHydrated和onDeleted
* @returns {FiberRoot}
*/
export function createFiberRoot(
containerInfo: any,
tag: RootTag,
hydrate: boolean,
hydrationCallbacks: null | SuspenseHydrationCallbacks,
): FiberRoot {
// 通過FiberRootNode構造函數創建一個fiberRoot實例
const root: FiberRoot = (new FiberRootNode(containerInfo, tag, hydrate): any);
if (enableSuspenseCallback) {
root.hydrationCallbacks = hydrationCallbacks;
}

// Cyclic construction. This cheats the type system right now because
// stateNode is any.
// 通過createHostRootFiber方法創建fiber tree的根節點,即rootFiber
// 需要留意的是,fiber節點也會像DOM樹結構一樣形成一個fiber tree單鍊表樹結構
// 每個DOM節點或者組件都會生成一個與之對應的fiber節點(生成的過程會在後續的文章中進行解讀)
// 在後續的調和(reconciliation)階段起著至關重要的作用
const uninitializedFiber = createHostRootFiber(tag);
// 創建完rootFiber之後,會將fiberRoot實例的current屬性指向剛創建的rootFiber
root.current = uninitializedFiber;
// 同時rootFiber的stateNode屬性會指向fiberRoot實例,形成相互引用
uninitializedFiber.stateNode = root;
// 最後將創建的fiberRoot實例返回
return root;
}

一個完整的FiberRootNode實例包含了很多有用的屬性,這些屬性在任務調度階段都發揮著各自的作用,可以在ReactFiberRoot.js文件中看到完整的FiberRootNode構造函數的實現(這裡只列舉部分屬性):

/**
* FiberRootNode構造函數
* @param containerInfo DOM容器
* @param tag fiberRoot節點的標記(LegacyRoot、BatchedRoot、ConcurrentRoot)
* @param hydrate 判斷是否是hydrate模式
* @constructor
*/
function FiberRootNode(containerInfo, tag, hydrate) {
// 用於標記fiberRoot的類型
this.tag = tag;
// 指向當前激活的與之對應的rootFiber節點
this.current = null;
// 和fiberRoot關聯的DOM容器的相關信息
this.containerInfo = containerInfo;
...
// 當前的fiberRoot是否處於hydrate模式
this.hydrate = hydrate;
...
// 每個fiberRoot實例上都只會維護一個任務,該任務保存在callbackNode屬性中
this.callbackNode = null;
// 當前任務的優先級
this.callbackPriority = NoPriority;
...
}

部分屬性信息如上所示,由於屬性過多並且在本文中暫時還用不到,這裡就先不一一列舉出來了,剩餘的屬性及其注釋信息已經上傳至Github(https://github.com/qq591468061/react-16.10.2),感興趣的朋友可以自行查看。在了解完了fiberRoot的屬性結構之後,接下來繼續探究createFiberRoot方法的後半部分內容:

// 以下代碼來自上文中的createFiberRoot方法
// 通過createHostRootFiber方法創建fiber tree的根節點,即rootFiber
const uninitializedFiber = createHostRootFiber(tag);
// 創建完rootFiber之後,會將fiberRoot實例的current屬性指向剛創建的rootFiber
root.current = uninitializedFiber;
// 同時rootFiber的stateNode屬性會指向fiberRoot實例,形成相互引用
uninitializedFiber.stateNode = root;

// 以下代碼來自ReactFiber.js文件
/**
* 內部調用createFiber方法創建一個FiberNode實例
* @param tag fiberRoot節點的標記(LegacyRoot、BatchedRoot、ConcurrentRoot)
* @returns {Fiber}
*/
export function createHostRootFiber(tag: RootTag): Fiber {
let mode;
// 以下代碼根據fiberRoot的標記類型來動態設置rootFiber的mode屬性
// export const NoMode = 0b0000; => 0
// export const StrictMode = 0b0001; => 1
// export const BatchedMode = 0b0010; => 2
// export const ConcurrentMode = 0b0100; => 4
// export const ProfileMode = 0b1000; => 8
if (tag === ConcurrentRoot) {
mode = ConcurrentMode | BatchedMode | StrictMode;
} else if (tag === BatchedRoot) {
mode = BatchedMode | StrictMode;
} else {
mode = NoMode;
}
...

// 調用createFiber方法創建並返回一個FiberNode實例
// HostRoot表示fiber tree的根節點
// 其他標記類型可以在shared/ReactWorkTags.js文件中找到
return createFiber(HostRoot, null, null, mode);
}

/**
* 創建並返回一個FiberNode實例
* @param tag 用於標記fiber節點的類型(所有的類型存放在shared/ReactWorkTags.js文件中)
* @param pendingProps 表示待處理的props數據
* @param key 用於唯一標識一個fiber節點(特別在一些列表數據結構中,一般會要求為每個DOM節點或組件加上額外的key屬性,在後續的調和階段會派上用場)
* @param mode 表示fiber節點的模式
* @returns {FiberNode}
*/
const createFiber = function(
tag: WorkTag,
pendingProps: mixed,
key: null | string,
mode: TypeOfMode,
): Fiber {
// $FlowFixMe: the shapes are exact here but Flow doesn't like constructors
// FiberNode構造函數用於創建一個FiberNode實例,即一個fiber節點
return new FiberNode(tag, pendingProps, key, mode);
};

至此我們就成功地創建了一個fiber節點,上文中我們提到過,和 DOM 樹結構類似,fiber節點也會形成一個與 DOM 樹結構對應的fiber tree,並且是基於單鍊表的樹結構,我們在上面剛創建的fiber節點可作為整個fiber tree的根節點,即RootFiber節點。在目前階段,我們暫時不用關心一個fiber節點所包含的所有屬性,但可以稍微留意一下以下相關屬性:

/**
* FiberNode構造函數
* @param tag 用於標記fiber節點的類型
* @param pendingProps 表示待處理的props數據
* @param key 用於唯一標識一個fiber節點(特別在一些列表數據結構中,一般會要求為每個DOM節點或組件加上額外的key屬性,在後續的調和階段會派上用場)
* @param mode 表示fiber節點的模式
* @constructor
*/
function FiberNode(
tag: WorkTag,
pendingProps: mixed,
key: null | string,
mode: TypeOfMode,
) {
// Instance
// 用於標記fiber節點的類型
this.tag = tag;
// 用於唯一標識一個fiber節點
this.key = key;
...
// 對於rootFiber節點而言,stateNode屬性指向對應的fiberRoot節點
// 對於child fiber節點而言,stateNode屬性指向對應的組件實例
this.stateNode = null;

// Fiber
// 以下屬性創建單鍊表樹結構
// return屬性始終指向父節點
// child屬性始終指向第一個子節點
// sibling屬性始終指向第一個兄弟節點
this.return = null;
this.child = null;
this.sibling = null;
// index屬性表示當前fiber節點的索引
this.index = 0;
...

// 表示待處理的props數據
this.pendingProps = pendingProps;
// 表示之前已經存儲的props數據
this.memoizedProps = null;
// 表示更新隊列
// 例如在常見的setState操作中
// 其實會先將需要更新的數據存放到這裡的updateQueue隊列中用於後續調度
this.updateQueue = null;
// 表示之前已經存儲的state數據
this.memoizedState = null;
...

// 表示fiber節點的模式
this.mode = mode;

// 表示當前更新任務的過期時間,即在該時間之後更新任務將會被完成
this.expirationTime = NoWork;
// 表示當前fiber節點的子fiber節點中具有最高優先級的任務的過期時間
// 該屬性的值會根據子fiber節點中的任務優先級進行動態調整
this.childExpirationTime = NoWork;

// 用於指向另一個fiber節點
// 這兩個fiber節點使用alternate屬性相互引用,形成雙緩衝
// alternate屬性指向的fiber節點在任務調度中又稱為workInProgress節點
this.alternate = null;
...
}

其他有用的屬性筆者已經在源碼中寫好相關注釋,感興趣的朋友可以在Github上查看完整的注釋信息幫助理解。當然在現階段,其中的一些屬性還暫時難以理解,不過沒有關係,在後續的內容和系列文章中將會逐個擊破。在本小節中我們主要是為了理解FiberRoot和RootFiber這兩個容易混淆的概念以及兩者之間的聯繫。同時在這裡我們需要特別注意的是,多個fiber節點可形成基於單鍊表的樹形結構,通過自身的return,child和sibling屬性可以在多個fiber節點之間建立聯繫。為了更加容易理解多個fiber節點及其屬性之間的關係,這裡先回顧一下在上一篇文章中的簡單示例,我們在src/App.js文件中將create-react-app腳手架生成的默認根組件App修改為如下形式:

import React, {Component} from 'react';

function List({data}) {
return (
<ul className="data-list">
{
data.map(item => {
return <li className="data-item" key={item}>{item}</li>
})
}
</ul>
);
}

export default class App extends Component {

constructor(props) {
super(props);
this.state = {
data: [1, 2, 3]
};
}

render() {
return (
<div className="container">
<h1 className="title">React learning</h1>
<List data={this.state.data} />
</div>
);
}
}

最終生成的 DOM 結構如下所示:

<div class="container">
<h1 class="title">React learning</h1>
<ul class="data-list">
<li class="data-item">1</li>
<li class="data-item">2</li>
<li class="data-item">3</li>
</ul>
</div>

基於該 DOM 結構再結合上文中對源碼的分析過程,最後我們可以嘗試得出一張關係圖來加深印象:

總結

本文主要是在上一篇文章內容的基礎之上從零開始逐行分析ReactDOM.render方法的實現原理,其背後的實現過程和調用棧還是非常複雜的,自己也是處於不斷的摸索過程中。在本文中主要是介紹兩個核心概念:FiberRoot和RootFiber,只有理解並區分這兩個概念之後才能更好地理解 React 的Fiber架構和任務調度階段中任務的執行過程。閱讀源碼的過程是痛苦的,但與此同時自己所獲得的收益也是巨大的,為了避免文章過於枯燥,還是打算將源碼內容劃分到系列文章中來單獨解讀,期間的間隔時間可用於對之前內容進行回顧,避免一口吃個胖子反而效果不好。

 

相關焦點

  • React 源碼分析(1):調用ReactDOM.render後發生了什麼
    )-調用ReactDOM.render後發生了什麼/所謂知其然還要知其所以然.在這之前, 假設讀者已經:如何分析 React 源碼代碼架構預覽首先, 我們找到React在Github上的地址, 把15-stable版本的源碼copy下來, 觀察它的整體架構, 這裡首先閱讀關於源碼介紹的官方文檔, 再接著看.
  • React 源碼解讀之 Custom Renderer
    對於 Web 平臺,這個 Renderer 就是 react-dom,對於 Native 平臺,這個 Renderer 就是 react-native。接下來看看 CanvasRenderer.render 函數做了啥:const reconcilerInstance = Reconciler(HostConfig)const CanvasRenderer = {  render(element, renderDom, {width, height, style}, callback
  • 為什麼我說你應該學React源碼?
    (會根據你簡歷中寫的技術棧來)React 中各種組件復用的優劣勢(mixin、render props、hoc、hook)React新的生命周期,為什麼 getDrivedStatefromProps 是靜態的?可以很清楚地看到,以上大部分問題都是React 原理層面的問題。
  • React源碼分析與實現(一):組件的初始化與渲染
    React源碼分析與實現(一):組件的初始化與渲染原文連結地址:https://github.com/Nealyang 前言戰戰兢兢寫下開篇…也感謝小蘑菇大神以及網上各路大神的博客資料參考~閱讀源碼的方式有很多種,廣度優先法、調用棧調試法等等,此系列文章,採用基線法,顧名思義,就是以低版本為基線,逐漸了解源碼的演進過程和思路。
  • 手寫React-Router源碼,深入理解其原理
    BrowserRouter源碼 我們代碼裡面最外層的就是BrowserRouter,我們先去看看他的源碼幹了啥,地址傳送門:https://github.com/ReactTraining/react-router/blob/master/packages/react-router-dom/modules/BrowserRouter.js
  • 【React源碼筆記】setState原理解析
    為什麼多次更新state的值會被合併只會觸發一次render?為什麼直接修改this.state無效???帶著這麼多的疑問,因為剛來需求也不多,對setState這一塊比較好奇,那我就默默clone了react源碼。今天從這四個有趣的問題入手,用setState跟大家深入探討state的更新機制,一睹setState的芳容。
  • React源碼解析,實現一個React
    本文希望通過參考 React 源碼,依葫蘆畫瓢地完成React的雛形。來幫助理解其內部的實現原理,知其然更要知其所以然。下面是VirtualDOM節點的定義:入口一切都是從 React.render(<App/>, document.body) 開始的,所以先來看看 React是怎麼定義的?
  • 【前端技術】react渲染 - 流程概述
    實際上jsx 是來源於一個前端框架 react。在react中除了我們了解的jsx,那麼jsx在react的渲染過程是哪個環節生效,以及渲染過程經歷了哪些步驟。本文會基於這些點進行概述。1.本文的react.render樹狀圖.xmind,此為作者查看/調試react的渲染源碼時做的結構筆記。
  • 「源碼解析 」這一次徹底弄懂react-router路由原理
    寫在前面:為什麼要學習react-router底層源碼? 為什麼要弄明白整個路由流程?
  • React 16.8 之 React Hook
    (點擊上方 前端腦洞,可快速關注,感謝分享)Hook 是 React 16.8 的新增特性。它可以讓你在不編寫 class 的情況下使用 state 以及其他的 React 特性.React Hook 為何而存在1.在組件之間復用狀態邏輯很難雖然我們可以用render props 和高階組件來解決這一問題,但是這不僅會容易形成「嵌套地獄」,還會面臨一個很尷尬的問題,那就是複雜邏輯難寫
  • React 16.8發布:hooks終於來了!
    我們在最近發布的 React 路線圖(https://reactjs.org/blog/2018/11/27/react-16-roadmap.html)中描述了未來幾個月的計劃。請注意,React hooks 還沒有涵蓋類的所有用例,但已經非常接近了。
  • React系列-Mixin、HOC、Render Props
    上)React系列-輕鬆學會Hooks(中)React系列-自定義Hooks很簡單(下)用了一段時間的Hooks,結合幾篇文檔,整理些筆記📒在講react-hooks之前,我們來捋捋react狀態邏輯復用相關知識點,這會幫助你理解hooksReact 裡,組件是代碼復用的基本單元,基於組合的組件復用機制相當優雅。
  • React 源碼解讀之Hooks
    說明:本文結論均基於 React 16.13.1 得出,若有出入請參考對應版本源碼題目老規矩,在進入正題前,先做個題目:下面的組件能按照期望工作嗎(每隔一秒數字增加 1)?Why?We can bail out without scheduling React to re-render.
  • 我一定把 React-Router 的真諦給你整地明明白白的
    BrowserRouter源碼我們代碼裡面最外層的就是BrowserRouter,我們先去看看他的源碼幹了啥,地址傳送門:https://github.com/ReactTraining/react-router/blob/master/packages/react-router-dom/modules/BrowserRouter.js
  • 【重學React】動手實現一個react-redux
    react-redux 是什麼react-redux 是 redux 官方 React 綁定庫。它幫助我們連接UI層和數據層。本文目的不是介紹 react-redux 的使用,而是要動手實現一個簡易的 react-redux,希望能夠對你有所幫助。
  • react源碼分析之-setState是異步還是同步?
    寫在前面的話setState是React很重要的模塊, 社區中也有很多分析文章,大多強調setState是異步更新,但有些文章分析又說某些情況下是同步更新,那到底是同步還是異步呢,這篇文章還是[基於15.x]()進行的分析,16
  • 手撕React學算法:React.Children-遞歸和對象池
    js中對象池的實現可以參照React 16.8.6之前的getPooledTraverseContext releaseTraverseContext這兩個方法。先來看一下這段代碼import React from 'react';class App extends React.Component { render(){ console.log(this.props.children) console.log(React.Children.map(
  • React組件邏輯復用的那些事兒
    當然,如果你曾經在低版本的 react 中使用過 Mixins,例如 react-timer-mixin, react-addons-pure-render-mixin,那麼你可能知道,在 React 的新版本中我們其實還是可以使用 mixin,雖然 React.createClass 已經被移除了,但是仍然可以使用第三方庫 create-react-class,來繼續使用 mixin。
  • 面試題:React中setState是異步還是同步?
    在學習react的過程中幾乎所有學習材料都會反覆強調一點setState是異步的,來看一下react官網對於setState的說明。
  • react的核心api-前端進階
    資源 1. react 2. create-r eact-app 起步 1. 安裝官方腳手架: npm install -g create-react-app 2.創建項目: create-react-app react-study 3.