[JavaScript知识库]React 配置化+Serverless 开发个人博客「完结」

Download: React 配置化+Serverless 开发个人博客

React17新特性：启发式更新算法

高清【课代表\/: ebing6】一起学习

React 17版本不寻常，因为它没有添加任何面向开发人员的新功能。取而代之的是，此发行版主要侧重于使其更易于升级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")