Solid与React对比

在现代前端开发中，Solid.js和React是两个备受关注的框架。虽然它们都致力于构建高效的用户界面，但在实现方式上却有着显著的差异。本文将深入探讨这两个框架的核心概念、源码实现和性能优化策略，帮助开发者更好地理解它们的设计理念。

State：组件的记忆

Solid.js的createSignal

Solid 响应性原理大致上是将任何响应性计算封装在函数中，并在其依赖关系更新时重新运行该函数。Solid JSX 编译器还用一个函数包装了大多数 JSX 表达式（括号中的代码），因此当依赖关系发生变化时，它们会自动更新（并触发相应的 DOM 更新）。更准确地说，每当函数在跟踪范围内被调用时，就会自动重新运行该函数，例如 JSX 表达式或构建 “计算” 的 API 调用（createEffect, createMemo 等）。signal 是最基本的响应性API,它们跟踪随时间变化的单个值（可以是任何 JavaScript 对象）。

Solid.js的响应式系统核心是createSignal函数：

javascript

function createSignal(value, options) {
  const s = {
    value,
    observers: null,
    observerSlots: null,
    comparator: options && options.equals ? options.equals : undefined,
  };
  return [readSignal.bind(s), writeSignal.bind(s)];
}

function readSignal() {
  if (Listener) {
    // 建立依赖关系
  }
  return this.value;
}

function writeSignal(value) {
  if (this.comparator && this.comparator(this.value, value)) return value;
  this.value = value;
  if (this.observers && this.observers.length) {
    runUpdates(() => {
      for (let i = 0; i < this.observers.length; i++) {
        const observer = this.observers[i];
        observer.state && observer.state();
      }
    });
  }
  return value;
}

Solid.js通过闭包来封装状态，并通过观察者模式来管理依赖关系：

createSignal函数：

创建一个包含value、observers、observerSlots和comparator的对象。返回一个数组，包含绑定了上下文的readSignal和writeSignal函数。

readSignal函数：

如果存在Listener（通常是一个计算效果），建立信号和Listener之间的双向依赖关系。这种双向关系允许精确追踪哪些计算依赖于哪些信号，实现细粒度更新。

writeSignal函数：

首先检查是否需要更新（通过可选的comparator）。如果值发生变化，更新value并通知所有观察者。使用runUpdates来批量处理更新，提高性能。

这种设计允许Solid.js实现非常高效的响应式系统。每个信号知道哪些计算依赖它，每个计算也知道它依赖哪些信号。这种双向追踪使得Solid.js能够精确地更新只有那些真正受影响的部分，而不是重新渲染整个组件树。

React的useState

组件通常需要根据交互更改屏幕上显示的内容。输入表单应该更新输入字段，单击轮播图上的“下一个”应该更改显示的图片，单击“购买”应该将商品放入购物车。组件需要“记住”某些东西：当前输入值、当前图片、购物车。这种组件特有的记忆在 React 中被称为 state。

相比Solid的createSignal，React的useState hook的实现要复杂得多，因为它需要与React的整个生命周期和调度系统集成。以下是一个简化版的实现：

javascript

function useState(initialState) {
  const dispatcher = resolveDispatcher();
  return dispatcher.useState(initialState);
}

// 在React内部
function resolveDispatcher() {
  const dispatcher = ReactCurrentDispatcher.current;
  if (dispatcher === null) {
    throw Error('Hooks can only be called inside the body of a function component.');
  }
  return dispatcher;
}

// Hook的实际实现
function mountState(initialState) {
  const hook = mountWorkInProgressHook();
  if (typeof initialState === 'function') {
    initialState = initialState();
  }
  hook.memoizedState = hook.baseState = initialState;
  const queue = (hook.queue = {
    pending: null,
    dispatch: null,
    lastRenderedReducer: basicStateReducer,
    lastRenderedState: initialState,
  });
  const dispatch = (queue.dispatch = dispatchAction.bind(null, currentlyRenderingFiber, queue));
  return [hook.memoizedState, dispatch];
}

React的useState实现涉及到更多的内部机制：

它使用了一个dispatcher系统，允许React在不同的阶段（如渲染、更新）使用不同的实现。
状态是存储在fiber节点的hooks链表中，而不是像Solid.js那样直接封装在闭包里。
更新是通过调度系统来管理的，这允许React实现批量更新和并发模式等高级特性。
React的这种设计使得它能够支持更复杂的场景，如时间切片和优先级调度，但也增加了系统的复杂性。

这种差异反映了两个框架的不同设计理念：Solid.js追求简单高效的响应式更新，而React则致力于提供一个灵活且功能丰富的组件模型。

更新机制的差异

Solid.js的细粒度更新

Solid.js通过直接操作DOM来实现高效更新。看一个更复杂的例子来理解这一机制：

javascript

function TodoList() {
  const [todos, setTodos] = createSignal([]);
  const [newTodo, setNewTodo] = createSignal('');

  const addTodo = (e) => {
    e.preventDefault();
    setTodos([...todos(), { id: Date.now(), text: newTodo(), completed: false }]);
    setNewTodo('');
  };

  const toggleTodo = (id) => {
    setTodos(
      todos().map((todo) => (todo.id === id ? { ...todo, completed: !todo.completed } : todo)),
    );
  };

  return (
    <div>
      <form onSubmit={addTodo}>
        <input type="text" value={newTodo()} onInput={(e) => setNewTodo(e.target.value)} />
        <button type="submit">Add Todo</button>
      </form>
      <ul>
        <For each={todos()}>
          {(todo) => (
            <li>
              <input
                type="checkbox"
                checked={todo.completed}
                onChange={() => toggleTodo(todo.id)}
              />
              <span style={{ textDecoration: todo.completed ? 'line-through' : 'none' }}>
                {todo.text}
              </span>
            </li>
          )}
        </For>
      </ul>
    </div>
  );
}

在这个例子中：

每个信号（todos和newTodo）都直接与DOM中的特定部分关联。
当newTodo信号更新时，只有输入框的值会改变。
当todos信号更新时，Solid.js的<For>组件会智能地只更新变化的部分，而不是重新渲染整个列表。
复选框的状态和文本的样式都直接绑定到各个todo项的completed属性，确保高效的更新。

这种细粒度的更新机制使得Solid.js能够在处理大量数据或频繁更新时保持高性能。

React的虚拟DOM树更新

React则通过虚拟DOM和调和过程来决定如何更新UI。：

javascript

function updateHostComponent(current, workInProgress, renderLanes) {
  // 比较props
  const oldProps = current.memoizedProps;
  const newProps = workInProgress.pendingProps;
  if (oldProps !== newProps) {
    // 更新DOM属性
    updateDOMProperties(instance, newProps, oldProps);
  }
  // 处理子元素
  const oldChildren = current.child;
  const newChildren = workInProgress.child;
  reconcileChildren(current, workInProgress, newChildren, renderLanes);
}

function reconcileChildren(current, workInProgress, nextChildren, renderLanes) {
  if (current === null) {
    // 挂载新组件
    workInProgress.child = mountChildFibers(workInProgress, null, nextChildren, renderLanes);
  } else {
    // 更新已存在的组件
    workInProgress.child = reconcileChildFibers(
      workInProgress,
      current.child,
      nextChildren,
      renderLanes,
    );
  }
}

React的更新过程涉及以下几个关键步骤：

对比新旧props，决定是否需要更新DOM属性。
使用reconciliation算法比较新旧子元素树，这个过程是递归的。
对于列表渲染，React使用key prop来优化更新过程，尽可能复用已存在的DOM节点。
生成一个"更新计划"，描述需要对实际DOM进行的最小化更改。
在commit阶段，React会一次性将这些更改应用到实际DOM上。

这个过程允许React在不直接操作DOM的情况下计算出最优的更新策略，这对于跨平台开发（如React Native）非常有利。然而，这也意味着React在某些情况下可能会做一些不必要的工作，特别是在处理大型列表或频繁更新时。

React的这种方法在处理复杂UI和大型应用时表现出色，因为它提供了一致的编程模型和优秀的开发者体验。但在某些高性能要求的场景下，可能需要额外的优化技巧（如useMemo、useCallback等）来避免不必要的重渲染。

组件模型对比

Solid.js的单次执行模型

Solid.js的组件只执行一次，建立响应式关系后不再重新执行。这种模型带来了一些独特的优势和考虑事项：

javascript

function ComplexComponent() {
  const [count, setCount] = createSignal(0);
  const [name, setName] = createSignal('John');

  // 这个console.log只会在组件首次渲染时执行一次
  console.log('Component rendered');

  const doubleCount = createMemo(() => count() * 2);

  createEffect(() => {
    console.log(`Count changed to ${count()}, double is ${doubleCount()}`);
  });

  return (
    <div>
      <h1>Hello, {name()}!</h1>
      <p>Count: {count()}</p>
      <p>Double Count: {doubleCount()}</p>
      <button onClick={() => setCount((c) => c + 1)}>Increment</button>
      <input value={name()} onInput={(e) => setName(e.target.value)} />
    </div>
  );
}

在这个例子中：

组件函数体只执行一次，建立初始的响应式关系。
createMemo创建了一个响应式计算，它只在其依赖（这里是count）变化时才重新计算。
createEffect设置了一个副作用，它会在count或doubleCount变化时自动执行。
JSX中的响应式值（如{count()}）会自动更新，无需重新执行整个组件函数。

这种模型的优势在于：

性能优化：初始化成本较低，后续更新非常高效。
清晰的依赖关系：响应式系统明确地追踪数据依赖。
减少错误：由于组件只执行一次，避免了由于重复执行可能导致的一些副作用问题。

然而，这也带来了一些需要注意的点：

学习曲线：开发者需要适应这种响应式的思维模式。
调试：由于组件只执行一次，某些调试技巧可能需要调整。

React的重复渲染模型

React组件在每次状态变化时都会重新执行。这种模型有其独特的优势和挑战：

javascript

function ComplexComponent() {
  const [count, setCount] = useState(0);
  const [name, setName] = useState('John');

  // 这个console.log会在每次组件重新渲染时执行
  console.log('Component rendered');

  const doubleCount = useMemo(() => count * 2, [count]);

  useEffect(() => {
    console.log(`Count changed to ${count}, double is ${doubleCount}`);
  }, [count, doubleCount]);

  return (
    <div>
      <h1>Hello, {name}!</h1>
      <p>Count: {count}</p>
      <p>Double Count: {doubleCount}</p>
      <button onClick={() => setCount((c) => c + 1)}>Increment</button>
      <input value={name} onChange={(e) => setName(e.target.value)} />
    </div>
  );
}

在这个React例子中：

每次状态（count或name）变化时，整个组件函数都会重新执行。
useMemo用于优化性能，只在count变化时重新计算doubleCount。
useEffect用于处理副作用，它会在count或doubleCount变化时执行。

这种模型的优势包括：

简单直观：组件的状态在每次渲染时都是新的，易于理解和推理。
灵活性：可以在每次渲染时根据最新的props和state做出决策。
一致性：所有组件遵循相同的生命周期，使得行为更可预测。

然而，这种模型也带来了一些挑战：

性能开销：频繁的重新渲染可能导致性能问题，特别是在复杂组件中。
优化需求：开发者需要使用useMemo、useCallback等钩子来优化性能。
副作用管理：需要小心处理副作用，以避免不必要的渲染、无限循环等。根据我的工作经验来看，这给初学者带来了较大的心智负担，给项目和团队带来了更高的复杂性和更多的工作量，尤其是你需要处理前辈们留下的一堆effect的时候（笑）。

虚拟DOM vs 编译时优化

React的虚拟DOM

虚拟DOM是JavaScript对象的树形结构，代表了实际DOM的结构。当组件的状态发生变化时，React会：

创建一个新的虚拟DOM树。
将新树与旧树进行比较（diff算法）。
计算出需要对实际DOM进行的最小化更改。
批量执行这些更改。

这个过程被称为协调（Reconciliation）。看看React是如何实现这个过程的：

javascript

function reconcileChildrenArray(returnFiber, currentFirstChild, newChildren, lanes) {
  let resultingFirstChild = null;
  let previousNewFiber = null;
  let oldFiber = currentFirstChild;
  let lastPlacedIndex = 0;
  let newIdx = 0;
  let nextOldFiber = null;

  // 首先尝试更新现有子元素
  for (; oldFiber !== null && newIdx < newChildren.length; newIdx++) {
    if (oldFiber.index > newIdx) {
      nextOldFiber = oldFiber;
      oldFiber = null;
    } else {
      nextOldFiber = oldFiber.sibling;
    }
    const newFiber = updateSlot(returnFiber, oldFiber, newChildren[newIdx], lanes);
    if (newFiber === null) {
      if (oldFiber === null) {
        oldFiber = nextOldFiber;
      }
      break;
    }
    if (shouldTrackSideEffects) {
      if (oldFiber && newFiber.alternate === null) {
        deleteChild(returnFiber, oldFiber);
      }
    }
    lastPlacedIndex = placeChild(newFiber, lastPlacedIndex, newIdx);
    if (previousNewFiber === null) {
      resultingFirstChild = newFiber;
    } else {
      previousNewFiber.sibling = newFiber;
    }
    previousNewFiber = newFiber;
    oldFiber = nextOldFiber;
  }

  // 处理剩余的新子元素或旧子元素
  // ...（省略部分代码）

  return resultingFirstChild;
}

这个复杂的过程允许React高效地更新DOM，即使在大型应用中也能保持良好的性能。

虚拟DOM的优势：

跨平台：同样的虚拟DOM可以渲染到不同的平台（Web、Native等）。
批量更新：多个更改可以在一次DOM操作中完成，提高性能。
声明式编程：开发者可以描述UI应该是什么样子，而不是如何更新它。

然而，虚拟DOM也有一些潜在的缺点：

内存开销：需要在内存中维护额外的JavaScript对象树。
学习曲线：理解和优化虚拟DOM可能需要一定的学习成本。

Solid.js的编译时优化

Solid.js采用了一种不同的方法，它在编译时就生成了高效的JavaScript代码。看一个例子：

javascript

function Counter() {
  const [count, setCount] = createSignal(0);
  return <div onClick={() => setCount(count() + 1)}>Count: {count()}</div>;
}

Solid.js会将这个组件编译成类似下面的代码：

javascript

import { createSignal as _createSignal } from 'solid-js';
import { insert as _insert, createComponent as _createComponent } from 'solid-js/web';

const _tmpl$ = /*#__PURE__*/ template(`<div>Count: </div>`);

function Counter() {
  const [count, setCount] = _createSignal(0);
  return (() => {
    const _el$ = _tmpl$.cloneNode(true);
    _el$.addEventListener('click', () => setCount(count() + 1));
    _insert(_el$, count, null);
    return _el$;
  })();
}

这种编译时优化的方法有几个关键优势：

直接DOM操作：生成的代码直接操作DOM，避免了虚拟DOM的开销。
模板克隆：使用_tmpl$.cloneNode(true)来克隆预先创建的DOM模板，这比每次都创建新的DOM元素更高效。
细粒度更新：_insert(_el$, count, null)只更新依赖于count的部分，而不是整个组件。
事件委托：事件监听器直接添加到DOM元素上，无需额外的事件系统。

这种方法的优势包括：

极高的性能：直接的DOM操作和细粒度更新带来了卓越的性能。
小的运行时：大部分工作在编译时完成，运行时库可以很小。
可预测的输出：编译后的代码行为非常明确，易于理解和调试。

然而，这种方法也有一些限制：

编译依赖：需要构建步骤，不能直接在浏览器中使用。
灵活性：某些动态行为可能更难实现，因为大部分优化在编译时完成。

响应式vs声明式编程

Solid.js的响应式方法

Solid.js采用了响应式编程模型，这种模型允许开发者精确地定义数据依赖关系。通过一个更复杂的例子来深入理解这一点：

javascript

import { createSignal, createMemo, createEffect, For } from 'solid-js';

function TodoApp() {
  const [todos, setTodos] = createSignal([]);
  const [filter, setFilter] = createSignal('all');

  const addTodo = (text) => {
    setTodos([...todos(), { id: Date.now(), text, completed: false }]);
  };

  const toggleTodo = (id) => {
    setTodos(
      todos().map((todo) => (todo.id === id ? { ...todo, completed: !todo.completed } : todo)),
    );
  };

  const filteredTodos = createMemo(() => {
    return todos().filter((todo) => {
      if (filter() === 'active') return !todo.completed;
      if (filter() === 'completed') return todo.completed;
      return true;
    });
  });

  const remainingCount = createMemo(() => {
    return todos().filter((todo) => !todo.completed).length;
  });

  createEffect(() => {
    console.log(`You have ${remainingCount()} todos left to complete`);
  });

  return (
    <div>
      <input type="text" onKeyPress={(e) => e.key === 'Enter' && addTodo(e.target.value)} />
      <For each={filteredTodos()}>
        {(todo) => (
          <div>
            <input type="checkbox" checked={todo.completed} onChange={() => toggleTodo(todo.id)} />
            <span style={{ textDecoration: todo.completed ? 'line-through' : 'none' }}>
              {todo.text}
            </span>
          </div>
        )}
      </For>
      <div>
        <button onClick={() => setFilter('all')}>All</button>
        <button onClick={() => setFilter('active')}>Active</button>
        <button onClick={() => setFilter('completed')}>Completed</button>
      </div>
      <div>{remainingCount()} items left</div>
    </div>
  );
}

在这个例子中：

createSignal用于创建响应式状态（todos和filter）。
createMemo用于创建派生状态（filteredTodos和remainingCount）。这些计算只在其依赖变化时才会重新执行。
createEffect用于处理副作用，比如日志记录。它会在其依赖（这里是remainingCount）变化时自动重新运行。
For组件用于高效地渲染列表，它会智能地只更新变化的项。
事件处理函数（如addTodo和toggleTodo）直接修改信号，触发相关的响应式更新。

这种响应式方法的优势在于：

细粒度更新：只有直接依赖变化的部分会被重新计算或渲染。
明确的数据流：依赖关系是显式的，易于理解和维护。
高性能：由于更新是精确的，不需要额外的比较或调和过程。

React的声明式方法

相比之下，React采用了一种更声明式的方法。用React重写上面的例子：

javascript

import React, { useState, useMemo, useEffect } from 'react';

function TodoApp() {
  const [todos, setTodos] = useState([]);
  const [filter, setFilter] = useState('all');

  const addTodo = (text) => {
    setTodos([...todos, { id: Date.now(), text, completed: false }]);
  };

  const toggleTodo = (id) => {
    setTodos(
      todos.map((todo) => (todo.id === id ? { ...todo, completed: !todo.completed } : todo)),
    );
  };

  const filteredTodos = useMemo(() => {
    return todos.filter((todo) => {
      if (filter === 'active') return !todo.completed;
      if (filter === 'completed') return todo.completed;
      return true;
    });
  }, [todos, filter]);

  const remainingCount = useMemo(() => {
    return todos.filter((todo) => !todo.completed).length;
  }, [todos]);

  useEffect(() => {
    console.log(`You have ${remainingCount} todos left to complete`);
  }, [remainingCount]);

  return (
    <div>
      <input type="text" onKeyPress={(e) => e.key === 'Enter' && addTodo(e.target.value)} />
      {filteredTodos.map((todo) => (
        <div key={todo.id}>
          <input type="checkbox" checked={todo.completed} onChange={() => toggleTodo(todo.id)} />
          <span style={{ textDecoration: todo.completed ? 'line-through' : 'none' }}>
            {todo.text}
          </span>
        </div>
      ))}
      <div>
        <button onClick={() => setFilter('all')}>All</button>
        <button onClick={() => setFilter('active')}>Active</button>
        <button onClick={() => setFilter('completed')}>Completed</button>
      </div>
      <div>{remainingCount} items left</div>
    </div>
  );
}

在这个React版本中：

useState用于创建状态（todos和filter）。
useMemo用于创建派生状态（filteredTodos和remainingCount）。这些计算会在依赖数组中的值变化时重新执行。
useEffect用于处理副作用，如日志记录。
React的JSX直接使用这些状态和计算结果，React会在它们变化时自动更新UI。

React的声明式方法的优势在于：

简单的心智模型：开发者只需描述UI在任何给定状态下应该是什么样子。
一致的更新机制：所有组件遵循相同的生命周期和更新规则。
强大的生态系统：大量的工具和库支持这种编程模型。

然而，这种方法也有一些潜在的缺点：

性能开销：React需要比较虚拟DOM树来决定如何更新UI，这在某些情况下可能导致不必要的工作。
优化复杂性：开发者可能需要手动优化（如使用useMemo和useCallback）来避免不必要的重新渲染。

性能优化策略

Solid.js的优化

Solid.js的性能优化主要来自于其设计理念和编译时优化：

编译时优化： Solid.js在编译阶段就生成了高效的JavaScript代码。例如：

javascript

function Counter() {
  const [count, setCount] = createSignal(0);
  return <div>{count()}</div>;
}

会被编译为：

javascript

const _tmpl$ = /*#__PURE__*/ template(`<div></div>`);

function Counter() {
  const [count, setCount] = createSignal(0);
  return (() => {
    const _el$ = _tmpl$.cloneNode(true);
    _insert(_el$, count);
    return _el$;
  })();
}

这种编译后的代码直接操作DOM，避免了运行时的开销。

细粒度更新： Solid.js的响应式系统允许精确地追踪依赖关系，只更新真正需要更新的部分。例如：

javascript

const [count, setCount] = createSignal(0);
const double = createMemo(() => count() * 2);

createEffect(() => {
  console.log('Count changed:', count());
});

在这个例子中，只有当count信号变化时，double和效果才会重新计算。

响应式依赖图： Solid.js在首次渲染时建立一个响应式依赖图，之后的更新都基于这个图进行。这允许系统快速确定哪些部分需要更新，而无需遍历整个组件树。
避免不必要的重渲染：由于Solid.js的组件只执行一次，它天生就避免了React中常见的不必要重渲染问题。

React的优化

React的性能优化策略更多地依赖于开发者的主动优化：

虚拟DOM diff： React通过比较新旧虚拟DOM树来最小化实际DOM操作。这个过程是自动的，但开发者可以通过提供稳定的keyprop来帮助React更好地识别列表项的变化。
批量更新： React会将多个状态更新合并为一次渲染，以减少不必要的重渲染。

javascript

function handleClick() {
  setCount((c) => c + 1);
  setFlag((f) => !f);
  // 在React 18中，这两次状态更新会被自动批处理
}

使用memo、useMemo和useCallback：这些API允许开发者手动优化组件和计算的重渲染：

javascript

const MemoizedComponent = React.memo(MyComponent);

const memoizedValue = useMemo(() => computeExpensiveValue(a, b), [a, b]);

const memoizedCallback = useCallback(() => doSomething(a, b), [a, b]);

代码分割和懒加载：使用React.lazy和Suspense可以实现组件的按需加载，提高初始加载性能：

javascript

const LazyComponent = React.lazy(() => import('./LazyComponent'));

function MyComponent() {
  return (
    <Suspense fallback={<div>Loading...</div>}>
      <LazyComponent />
    </Suspense>
  );
}

并发模式： React 18引入的并发模式允许React中断和恢复渲染过程，提高应用的响应性：

javascript

import { startTransition } from 'react';

function handleClick() {
  startTransition(() => {
    setCount((c) => c + 1);
  });
}

这里，startTransition告诉React这是一个可以延迟的更新，允许更紧急的更新（如用户输入）优先进行。

未来趋势：Signal的兴起

随着Preact、Vue等框架也开始采用Signal模式，我们可以看到前端开发正在向更细粒度的状态管理和更新机制发展。Signal提供了以下优势：

更精确的依赖追踪： Signal允许框架精确地知道哪些部分依赖于哪些状态，从而实现最小化的更新。
潜在的性能提升：由于更新更精确，Signal可以减少不必要的计算和渲染，特别是在大型应用中。
简化的状态管理： Signal提供了一种直观的方式来思考和管理状态变化，可能比传统的状态管理方案更容易理解和使用。

例如，Vue 3的组合式API就采用了类似Signal的反应式系统：

javascript

import { ref, computed, watchEffect } from 'vue'

const count = ref(0)
const double = computed(() => count.value * 2)

watchEffect(() => {
  console.log(`Count is ${count.value}, double is ${double.value}`)
})

// 在组件模板中
<template>
  <div>{{ count }} - {{ double }}</div>
</template>

其他框架也有着类似的Signal实现，比如Angular 信号、Preact 信号。

TC39（ECMAScript 标准委员会）最近公开了一个 Signal 提案，这个提案旨在为 JavaScript 语言本身引入原生的 Signal 支持，这可能会对未来的前端开发产生深远的影响。

如果这个提案被接受并最终成为语言标准，我们可能会看到：

更统一的响应式编程模型：不同的框架可能会采用相似的 Signal 实现，减少学习成本。
性能提升：原生实现可能会比库级别的实现更高效。
更好的跨框架兼容性：基于标准化的 Signal，不同框架之间的互操作性可能会提高。

TC39 Proposal for Signals (reactive primitives) is now public

PREACT: 介绍 Signals