乐趣区

关于前端:Signal更多前端框架的选择

大家好,我卡颂。

最近,AngularQwik的作者 MIŠKO HEVERY 发文示意 Signal 是前端框架的将来,并思考在 Angular 中实现它。

在此之前,VueSolid.jsPreactSvelte都已实现 Signal。实际上,signal 并不是一个新概念,他还有很多别名,比方:

  • 响应式更新
  • 细粒度更新

如果你理解过 Vue 响应式更新的实现原理,对 Signal 就不会生疏。

实际上,Signal的技术在 10 年前 Knockout 框架中就有利用。为什么这项技术正受到越来越多前端框架的青眼?

本文,让咱们一起探讨下这个话题。

欢送退出人类高质量前端交换群,带飞

signal 的实质

signal的实质,是将 对状态的援用 以及 对状态值的获取 分来到。这么说可能有点形象,让咱们先看一个 非 signal的例子。

以下是 React 中定义状态的形式:

function App() {const [state, dispatch] = useState(0);
  return <p onClick={() => dispatch(state + 1)
  }>{state}</p>
}

useState的返回值包含两局部:

  • state:状态的值
  • dispatch:状态的setter

能够发现,state耦合了 对状态的援用 以及 对状态值的获取 这两个含意。

再来看一个 signal 的例子。以下是同一个例子用 Solid.js 书写的样子:

function App() {const [getState, dispatch] = createSignal(0);
  return <p onClick={() => dispatch(getState() + 1)
  }>{getState()}</p>
}

createSignal的返回值包含两局部:

  • getState:对状态的援用
  • dispatch:状态的setter

区别就体现在 getState 上,其中:

  • getState是对状态的援用
  • getState()是对状态值的获取

也就是说,咱们能够不用立即获取状态的值,而是在须要的时候再获取(即在须要时再执行getState())。

这么做有什么益处呢?如果咱们在须要的时候再获取状态的值,就能感知以后的上下文环境。

举个很毛糙的例子,在上面的代码中,组件实例(Component实例)在 render 时会将全局变量 cpnContext 指向本人:

let cpnContext = null;

class Component {render() {
    cpnContext = this;
    // ... 省略逻辑
  }
}

那么在 createSignal 返回的 getState 办法外部,能够获取全局变量 cpnContext 来感知以后处于哪个组件的渲染流程:

function createSignal() {
  // ... 省略逻辑
  function getState() {
    const curContext = cpnContext;
    // ...
  }
  function dispatch {}
  return [getState, dispatch]
}

这么做的目标是建设 状态变动 须要更新哪个组件 之间的分割。

相比于 React,基于Signal 实现的框架会有两个劣势:

  • 更好的细粒度更新性能
  • 更好的DX(开发者体验)

更好的细粒度更新性能

因为 Signal 建设了状态与组件之间的分割,所以相比于 React 更有性能劣势。

比方,在我的电脑上,用 Svelte 渲染 1w 个 li,点击某个li 后扭转他的内容:

<ul>
  {#each items as item (item.id)}
      <li on:click={() => items[item.id].name = 'change!'}>{item.name}</li>
  {/each}
</ul>

从点击事件触发,到 Svelte 逻辑运行完,再到浏览器重排重绘,总用时 18.88ms,其中 Svelte 的逻辑执行只花了 9.5ms:

同样的例子用 React 实现,触发点击后总用时 98.5ms,其中 React 的逻辑执行了 89.38ms:

在这个例子中,React性能比 Svelte 差了一个数量级。之所以会有这样的差别,很大一部分起因在于Svlete 在更新前就晓得状态变动时须要更新哪个组件

而这所有的源头就在于Signal

更好的 DX

更好的开发者体验次要体现在两方面:

  1. Signal感知上下文环境的能力缩小了代码心智累赘

比方在 React 中,useEffect在应用时须要指明依赖的状态:

useEffect(() => {// ...state1, state2 变动后的逻辑}, [state1, state2])

如果采纳 Signal 的实现,状态能感知到本人在 useEffect 上下文环境,能够主动建设两者之间的分割,不必再放心少写依赖状态、闭包陷阱等问题,缩小心智累赘。

比方在 Vue 中,相似 useEffect(仅仅是性能相似,两者的用处其实是不同的) 的watch,就不须要显式指明依赖:

<script setup>
import {ref, watch} from 'vue'

const name = ref('')

watch(name, (newName, oldName) => {// ... 省略逻辑})
</script>
  1. 缩小开发者性能优化的心智累赘

应用 Signal 的框架通常能取得不错的运行时性能,所以不须要额定的性能优化API。反观React,开发者如果遇到性能问题,须要手动调用性能优化API(比方React.memouseMemoPureComponent)。

总结

有以上这么多长处,难怪很多框架都应用了 Signal。那么ReactSignal是什么态度呢?

React团队成员对此的观点是:

  1. 有可能引入相似 Signal 的原语
  2. Signal性能的确好,但他不太合乎 React 的理念

React的理念能够用一句话概括:UI 反映状态在某一刻的快照

既然是快照,那就不是部分的,而是个整体概念。在 React 中,状态更新会引起整个利用从新 render,就是对React 快照理念的最好诠释。

React现阶段的所有实现都是基于快照理念。所以,即便引入相似 Signal 的原语,可能也是相似 Mobx 这样的下层实现,而不是从底层重构。

我集体比拟偏向于认为:React团队抵赖 Signal 的长处,但因为积重难返,而且古代设施的性能通常是过剩的,所以性能问题并不是首要问题。

如果这个观点是正确的,那么 React 可能会在开发者体验(Signal的另一个长处)方面努致力。比方去年提出的 RFC: useEvent 可能就是这方面的一次尝试。

退出移动版