前端框架的未来:useSignal()

开发 前端
Signal 是在应用中存储状态的一种方式,类似于 React 中的 useState()。两者的关键区别在于,Signal 返回一个 getter 和一个 setter,而非响应式系统只返回一个值和一个 setter。

Signal(信号)是一种存储应用状态的形式,类似于 React 中的 ​​useState()​​。但是,有一些关键性差异使 Signal 更具优势。Vue、Preact、Solid 和 Qwik 等流行 JavaScript 框架都支持 Signal。

Signal 并不是最近才出现的,在此之前,它已经存在于 Knockout 等框架中。不过,在最近几年通过巧妙的编译器技巧和与 JSX 的深度集成极大地改进了它的开发者体验·,这使得它非常简洁并且使用起来很方便。

下面就来看看 Signal 都有哪些优势,为什么说它是前端框架的未来!

Signal 是什么?

Signal 和 State 之间的主要区别在于 Signal 返回一个 getter 和一个 setter,而非响应式系统返回一个值和一个 setter。

图片

注意: 有些响应式系统同时返回一个 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 是前端框架的未来!

责任编辑:姜华 来源: 前端充电宝
相关推荐

2014-11-03 10:20:49

2022-04-24 15:15:57

前端技术阿里

2013-10-24 10:40:23

前端框架

2019-10-16 18:00:44

AngularVueReact

2019-07-17 22:07:14

前端开发框架

2023-02-24 07:29:59

Signal前端框架

2020-05-12 09:02:20

前端开发技术

2014-05-26 16:47:32

2023-05-26 06:28:15

2024-02-02 08:33:00

Vue模板性能

2020-03-25 13:59:22

前端开发编程

2010-12-29 09:51:29

前端基础框架

2019-01-31 11:11:30

前端开发框架

2022-07-27 10:36:13

前端UI框架

2023-11-03 08:04:47

Web微前端框架

2022-09-07 21:31:19

微前端架构iframe

2024-01-06 17:53:11

前端框架方案

2020-04-09 15:35:43

前端开发框架

2023-07-28 06:51:43

2022-09-21 17:01:28

Fluttter
点赞
收藏

51CTO技术栈公众号