配置化+Serverless 開發個人部落格「附原始碼」
高清原畫 連結: https://pan.baidu.com/s/1d6YONkCi4u7T1ZBm1yZLYg 提取碼: iamh
作者-\/ 307570512
React17新特性：啟發式更新演算法
React 17版本不尋常，威❤ 307570512 因為它沒有新增任何面向開發人員的新功能。取而代之的是，此發行版主要側重於使其更易於升級React本身。
我們正在積極開發新的React功能，但它們不是此版本的一部分。React 17發行版是我們將其推廣到任何人的戰略的關鍵部分。
特別地，React 17是一個“墊腳石”版本，它使將由一個版本的React管理的樹嵌入到由另一個版本的React管理的樹中更加安全。
最理想的模型是：可以指定任意幾個優先順序，更新會以這些優先順序對應update生成頁面快照。
但是現有架構下，該方案實現上有瓶頸。
妥協之下，React17的解決方案是：指定一個連續的優先順序區間，每次更新都會以區間內包含的優先順序生成對應頁面快照。
這種優先順序區間模型被稱為lanes（車道模型）。
具體做法是：使用一個31位的二進位制代表31種可能性。
其中每個bit被稱為一個lane（車道），代表優先順序
某幾個lane組成的二進位制數被稱為一個lanes，代表一批優先順序
可以從原始碼中看到，從藍線一路劃下去，每個bit都對應一個lane或lanes。
當update產生，會根據React16同樣的啟發式方式，獲得如下優先順序的一種：
export const SyncLanePriority: LanePriority = 17;
export const SyncBatchedLanePriority: LanePriority = 16;
export const InputDiscreteLanePriority: LanePriority = 14;
export const InputContinuousLanePriority: LanePriority = 12;
export const DefaultLanePriority: LanePriority = 10;
export const TransitionShortLanePriority: LanePriority = 8;
export const TransitionLongLanePriority: LanePriority = 6;
其中值越高，優先順序越大。
比如：
點選事件回撥中觸發this.setState產生的update會獲得InputDiscreteLanePriority。
同步的update會獲得SyncLanePriority。
接下來，update會以priority為線索尋找沒被佔用的lane。
如果當前fiber樹已經存在更新且更新的lanes包含了該lane，則update需要尋找其他lane。
比如，InputDiscreteLanePriority對應的lanes為InputDiscreteLanes。
// 第4、5位為1
const InputDiscreteLanes: Lanes = 0b0000000000000000000000000011000;
該lanes包含第4、5位2個bit位。
如果其中
// 第五位為1
0b0000000000000000000000000010000
第五位的lane已經被佔用，則該update可以嘗試佔有後一個，即
// 第四位為1
0b0000000000000000000000000001000
如果InputDiscreteLanes的兩個lane都被佔用，則該update的優先順序會下降到InputContinuousLanePriority並繼續尋找空餘的lane。
這個過程就像：購物中心每一層（不同優先順序）都有一個露天停車場（lanes），停車場有多個車位（lane）。
我們先開車到頂樓找車位（lane），如果沒有車位就下一樓繼續找。
直到找到空餘車位。
由於lanes可以包含多個lane，可以很方便的區分IO操作（Suspense）與CPU操作。
當構建fiber樹進入構建Suspense子樹時，會將Suspense的lane插入本次更新選定的lanes中。
當構建離開Suspense子樹時，會將Suspense lane從本次更新的lanes中移除。
React16的expirationTimes模型只能區分是否>=expirationTimes決定節點是否更新。
React17的lanes模型可以選定一個更新區間，並且動態的向區間中增減優先順序，可以處理更細粒度的更新。
配置化+Serverless 實戰開發個人部落格
函式的無狀態探索
首先要明白，Serverless的幾個關鍵特性：執行成本更低、自動擴縮容、事件驅動、無狀態性。這裡面的無狀態性是說開發者可以直接將服務業務邏輯程式碼部署，執行在第三方提供的無狀態計算容器中。這裡的無狀態如果強行說前一次不影響後一次，沒有狀態的話，也只能是說在容器沒有被複用的情況下，是這樣的。但是在實際的專案中，為了降低冷啟動率，提高瞬時產生的高併發應對能力，容器的複用可能會讓這個“無狀態性“變得比較撲朔迷離，此處以騰訊雲的SCF為例，我們在控制檯建立一個函式，然後我們使用以下的程式碼進行測試：
# -*- coding: utf8 -*-
import json
def main_handler(event, context):
print("Test")
return("Hello World")
通過這一組測試，我們發現，這三個結果有點不太一樣：只有第一次請求的時候，執行了這條語句：
print("Not in main_handler")
那麼為什麼後幾次都沒有執行這條語句呢？是沒執行到這裡？還是因為容器複用的原因，在接下來的幾次跳過了這個步驟？為什麼會跳過這個步驟？為了讓程式更加有趣，我們來做這樣一個測試：
# -*- coding: utf8 -*-
import json
print("此處給tempNumber賦值")
tempNumber = 100
def main_handler(event, context):
print("temp number: ", tempNumber)
return("Hello World")