Signal（数据信号）是一种存放运用状态下的方式，类似 React 里的 useState()。 可是，有一些至关重要差别使 Signal 更有优势。Vue、Preact、Solid 和 Qwik 等时兴 JavaScript 架构也支持 Signal。
Signal 并非近期才会出现的，在这以前，已经存在 Knockout 等架构中。但是，在近几年根据巧妙地编译程序方法及与 JSX 深度集成化在很大程度上优化了它开发人员感受·，这使得它十分简约并且使用下去更方便。
下面一起来看看 Signal 都有什么优势，为何称它为 Web 框架的将来！
Signal 是啥？
Signal 和 State 间的关键区别就是 Signal 回到一个 getter 和一个 setter，并非响应式网站系统软件回到一个值与一个 setter。
留意： 有一些响应式网站系统软件与此同时回到一个 getter/setter，有的则回到2个独立的引入，但观念是一样的。
Signal 的优点
State 弄混了2个单独这个概念：
- StateReference：对状态下的引入。
- StateValue：存储在情况引入/存放里的实际值。
那么为什么回到一个 getter 比回到一个值比较好呢？ 因为通过回到 getter，能将情况提及的传送与状态值的载入分离。
下边以这段 SolidJS 编码为例子：
createSignal()：分派 StateStorage 并把它复位为 0。getCount：能够传送对状态下的引入。getCount()：获得状态值。
上边阐述了 Signal 与普通 State 的差异。那 Signal 究竟有什么优点呢？Signal 是响应式网站的，这就意味着这需要追踪谁对情况有兴趣（订阅者），假如情况产生变化，则通告订阅者情况转变。
为了能具备响应式网站，Signal 一定要搜集谁对它值有兴趣。它仔细观察什么样的情况启用情况 getter 来获得此信息内容。根据从 getter 中获得值，告知 Signal 该部位对于该值有兴趣。 假如值产生变化，就需要启用 getter 创建一个定阅。
这也是为什么传送情况 getter 而非状态值非常重要的缘故。状态值的传送不容易向 Signal 提供有关具体使用这个系数的区域的任何信息。这也是为什么区别情况引入和状态值在 Signal 中如此重要。
为了能进行比较，欢迎来到 Qwik 里的同样实例。 一定要注意，(getter/setter) 已经被替换为具备 .value 特性（表明 getter/setter）的单独目标。尽管词法不一样，但内部结构工作原理是一样的。
当点击按键并增长值时，架构只需将文本节点从 0 升级为 1。它要这样做这是因为在模板的原始3D渲染期内，Signal 已知道 count.value 很容易被文本节点浏览。 因而，它知道假如 count 数值产生变化，就只需升级文本节点而不需要升级别的地方。
useState() 的缺陷
下面一起来看看在 React 中是怎样应用 useState() 的以及它的缺陷。
React 的 useState() 会回到一个状态值。这就意味着 useState() 不清楚部件或运用内部结构怎么使用状态值。因此，一旦根据启用 setCount() 通告 React 情况变更，React 也不知道界面的哪一部分出现了变更，所以必须再次3D渲染全部部件，这一点在测算上是非常昂贵。
useRef() 不3D渲染
React 的 useRef() 类似 useSignal()，但是它不会导致网页页面再次3D渲染。下边的事例看上去与 useSignal() 十分相似，但是它失灵。
useRef() 的使用与 useSignal() 完全一样，用以传送对状态下的引入而非情况自身。 可是，useRef() 缺少了定阅跟踪和通告。
在根据 Signal 的框架中，useSignal() 和 useRef() 是一样的。useSignal() 能够实行 useRef() 再加上定阅追踪的功效，这个就进一步优化了框架的 API。
内置的 useMemo()
Signal 不大要进行记忆力，因为他应该做的工作中非常少。
下边来说一个含有2个电子计数器或两个子组件的事例：
这儿只能升级2个 Display 部件之一的文本节点。未升级更新的文本节点在原始3D渲染之后将从来不会打印出。
# 原始3D渲染导出
<Counter/>
<Display count={0}/>
<Display count={0}/>
# 点击时的3D渲染
(空缺)
事实上，我们不能在 React 中获得同样的实际效果，由于最少会有一个部件需重新3D渲染。那样下面一起来看看怎样在 React 中记忆力部件以降到最低再次3D渲染次数。
但即便展开了记忆力，React 也会带来数次再次3D渲染：
# 原始3D渲染导出
<Counter/>
<Display count={0}/>
<Display count={0}/>
# 点击时的3D渲染
<Counter/>
<Display count={1}/>
假如没有记忆，我们会看到：
# 原始3D渲染导出
<Counter/>
<Display count={0}/>
<Display count={0}/>
# 点击时的3D渲染
<Counter/>
<Display count={1}/>
<Display count={0}/>
这个比 Signal 应该做的工作中多很多。因此，这也是为什么 Signal 工作如同把所有事情都记住了，而不需要由我们自己去记忆力。
举例说明
下面来看一个完成加入购物车的事例（React）：
APP 部件中定义了加入购物车状态 cart 及其2个子组件：
- Main 部件：根据双层部件传送 setCart 函数公式，直至它抵达购买按钮。
- NavBar 部件：根据双层部件传送加入购物车情况，直至它抵达3D渲染加入购物车的部件。
这儿的问题在于每一次点一下购买按钮时，绝大多数部件树都必须要再次3D渲染。这会导致相近于的导出：
# 点一下购买按钮时
<App/>
<Main/>
<Product/>
<NavBar/>
<Cart/>
如果采用记忆力，那样就能避免 Main 部件再次3D渲染，而仅有 NavBar 部件再次3D渲染：
# 点一下购买按钮时
<App/>
<NavBar/>
<Cart/>
如果采用 Signal，导出是这样子的：
# 点一下购买按钮时
<Cart/>
这大大减少了必须实行的代码量。
汇总
Signal 要在运用中存取数据的一种方式，类似 React 里的 useState()。二者的重要区别就是，Signal 回到一个 getter 和一个 setter，并非响应式网站系统软件只回到一个值与一个 setter。
Signal 是响应式网站的，这就意味着这需要追踪谁对情况有兴趣并告知订阅者情况变更。这也是仔细观察启用情况 getter 的前后文来完成的，它创建了一个定阅。
比较之下，React 里的 useState() 仅回到状态值，这就意味着它不知道该如何应用状态值，而且需要再次3D渲染全部部件树以回应情况转变。
因此，Signal 才算是 Web 框架的将来！
参照：www.builder.io/blog/usesig…