Signal(信号)是一种存储应用状态的形式,类似于 React 中的 useState()
。但是,有一些关键性差异使 Signal 更具优势。Vue、Preact、Solid 和 Qwik 等流行 JavaScript 框架都支持 Signal。
Signal 并不是最近才出现的,在此之前,它已经存在于 Knockout 等框架中。不过,在最近几年通过巧妙的编译器技巧和与 JSX 的深度集成极大地改进了它的开发者体验·,这使得它非常简洁并且使用起来很方便。
下面就来看看 Signal 都有哪些优势,为什么说它是前端框架的未来!
Signal 是什么?
Signal 和 State 之间的主要区别在于 Signal 返回一个 getter 和一个 setter,而非响应式系统返回一个值和一个 setter。
![512a37d1ed48ba51ae1b5d297b9f64de.png](https://i-blog.csdnimg.cn/blog_migrate/6f0a62b52757b96f5c21d3f1ea4bfbd0.png)
注意: 有些响应式系统同时返回一个 getter/setter,有些则返回两个单独的引用,但思想是一样的。
Signal 的优势
State 混淆了两个独立的概念:
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。它可以这样做是因为在模板的初始渲染期间,Signal 已经知道
count.value
只能被文本节点访问。因此,它知道如果 count
的值发生变化,就只需要更新文本节点而无需更新其他地方。
useState() 的缺点
下面来看看在 React 中是如何使用 useState()
的以及它的缺点。
React 的
useState()
会返回一个状态值。这意味着 useState()
不知道组件或应用内部如何使用状态值。所以,一旦通过调用 setCount()
通知 React 状态更改,React 就不知道页面的哪一部分发生了更改,因此必须重新渲染整个组件,这在计算上是很昂贵的。
useRef() 不渲染
React 的 useRef()
类似于 useSignal()
,但它不会导致页面重新渲染。下面的例子看起来与 useSignal()
非常相似,但它不起作用。
useRef()
的使用与 useSignal()
完全一样,用于传递对状态的引用而不是状态本身。但是,useRef()
缺少了订阅跟踪和通知。
在基于 Signal 的框架中,useSignal()
和 useRef()
是一样的。useSignal()
可以执行 useRef()
加上订阅跟踪的功能,这样就进一步简化了框架的 API。
内置的 useMemo()
Signal 很小需要进行记忆,因为它需要做的工作很少。
下面来看一个包含两个计数器和两个子组件的例子:
这里只会更新两个 Display 组件之一的文本节点。未更新的文本节点在初始渲染后将永远不会打印。
# 初始渲染输出
<Counter/>
<Display count={0}/>
<Display count={0}/>
# 单击时的渲染
(空白)
实际上,我们无法在 React 中实现相同的效果,因为至少会有一个组件需要重新渲染。那么下面就来看看如何在 React 中记忆组件以最小化重新渲染的次数。
但即使进行了记忆,React 也会产生多次重新渲染:
# 初始渲染输出
<Counter/>
<Display count={0}/>
<Display count={0}/>
# 单击时的渲染
<Counter/>
<Display count={1}/>
如果没有记忆,我们会看到:
# 初始渲染输出
<Counter/>
<Display count={0}/>
<Display count={0}/>
# 单击时的渲染
<Counter/>
<Display count={1}/>
<Display count={0}/>
这比 Signal 需要做的工作多得多。所以,这就是为什么 Signal 的工作就像把所有事情都记下来了,而不必由我们自己来记忆。
举个例子
下面就来看一个实现购物车的例子(React):
APP 组件中定义了购物车的状态
cart
以及两个子组件:
Main 组件:通过多层组件传递 setCart 函数,直到它到达购买按钮。
NavBar 组件:通过多层组件传递购物车状态,直到它到达渲染购物车的组件。
这里的问题就是每次点击购买按钮时,大部分组件树都必须重新渲染。这会导致类似于的输出:
# 点击购买按钮时
<App/>
<Main/>
<Product/>
<NavBar/>
<Cart/>
如果使用记忆,那么就可以避免 Main 组件重新渲染,而只有 NavBar 组件重新渲染:
# 点击购买按钮时
<App/>
<NavBar/>
<Cart/>
如果使用 Signal,输出是这样的:
# 点击购买按钮时
<Cart/>
这大大减少了需要执行的代码量。
总结
Signal 是在应用中存储状态的一种方式,类似于 React 中的 useState()
。两者的关键区别在于,Signal 返回一个 getter 和一个 setter,而非响应式系统只返回一个值和一个 setter。
Signal 是响应式的,这意味着它需要跟踪谁对状态感兴趣并通知订阅者状态更改。这是通过观察调用状态 getter 的上下文来实现的,它创建了一个订阅。
相比之下,React 中的 useState()
仅返回状态值,这意味着它不知道如何使用状态值,并且必须重新渲染整个组件树以响应状态变化。
所以说 Signal 是前端框架的未来!
- END -
关于奇舞团
奇舞团是 360 集团最大的大前端团队,代表集团参与 W3C 和 ECMA 会员(TC39)工作。奇舞团非常重视人才培养,有工程师、讲师、翻译官、业务接口人、团队 Leader 等多种发展方向供员工选择,并辅以提供相应的技术力、专业力、通用力、领导力等培训课程。奇舞团以开放和求贤的心态欢迎各种优秀人才关注和加入奇舞团。