Solid 的内部 API 中的 Listener、Transition 和 Scheduler 做什么？

Question

我正在阅读 Solid JS 的源代码，但我发现代码中的注释很少。 Solid 比 React 简单很多，但是在 React 的代码中可以找到很多注释。为什么没有解释关键概念的评论或文档？

请你解释一下

Listener

、

Transition

和

Scheduler

的作用：

let Listener: Computation<any> | null = null;
export let Transition: TransitionState | null = null;
let Scheduler: ((fn: () => void) => any) | null = null;

Answer 1

缺少注释并不一定意味着缺少文档，但你说对了一部分，因为内部 API 没有足够的文档记录。我相信有几个因素：

1. 核心团队很小，大部分代码由其创建者 Ryan Carniato 编写，并由他维护。

2. 没有 React 代码那么多的优化技巧，因为 Solid 足够快。因此，没有极端情况，代码足够干净，可以通读。

3. 年轻且不断发展的项目。 API 稳定但 Solid 并未广泛用于生产应用程序。有模式和用例出现。当项目成熟时，它将被重写，并希望它能被更好地记录下来。

4. 关于其核心逻辑和设计决策，有详细的文章和屏幕截图。

同样，暴露的 API 有很好的文档记录，并且有足够多的示例。内部 API 非常小且干净，足以阅读。

现在，解释问题中的代码片段：

代码属于信号的内部API。

Solid 是一个同步库。代码是同步执行的，与 React 等其他框架相反，您永远不会跨越异步边界。 Point is Solid 不依赖事件循环来运行批量更新，而是处理代码，这意味着它将信号的订阅者推送到另一个变量，运行状态更新，取回存储的变量并通知订阅者。 Solid 使用观察者模式 来通知订阅者。

在 Solid 中，每个信号都有自己的订阅者。没有全球订阅者队列。

Listener

被运行时用来存储订阅者并回调他们。如果我没记错的话，运行时将信号的侦听器存储在

Listener

中然后开始工作。结合调度程序和批量更新更好地理解。

Transitions

用于异步一致性。它们在相关异步任务完成时存储状态更新。假设您正在呈现与页码等查询参数相关联的远程数据。当您更新页码时，将创建一个中间状态并发送请求，但实际状态更新将存储在转换中，一旦请求稳定下来就会运行。主要思想是页码和与页码相关的呈现数据始终保持一致。它是批量更新的一种形式，但与异步任务绑定。

您可以阅读有关异步一致性的更多信息：https://dev.to/this-is-learning/why-all-the-suspense-understanding-async-consistency-in-javascript-frameworks-3kdp

Scheduler

用于安排 UI 更新。在常规的 pub-sub 模型中，订阅者被回调并且事件链立即运行且不受干扰。但是，如果您有很多移动件，则这不是最佳选择。 Scheduler 允许 Solid 运行时在运行效果时切换任务。通过运行效果，我的意思是给订阅者回电。