在名为“Runes简介”的博客文章中,Svelte 团队展示了在 web 应用中表述反应式依赖的新语法。这种额外的语法可以提高复杂 web 应用的可维护性,进一步推进 Svelte 的企业级就绪度。
Svelte 即将推出的 runes 能够让开发人员将反应式逻辑分解并封装为标准的 JavaScript 函数,这些函数能够在整个代码库中重复使用。
在 Svelte 3 中,反应式依赖是通过.svelte
文件在组件级别描述的。组件会封装一些在组件外部不可见的反应式依赖(let var
语法),或者明确声明外部的反应式依赖(export let var
),客户端组件可以通过Svelte的props语法使用这些依赖。对于那些既不属于本地组件,又不方面在组件接口中公开的反应式依赖,开发人员可以导入Svelte存储。
Svelte 的单文件组件强烈建议开发人员将组件的三个关注点(样式、内容和行为)放到一个文件中。当这三个关注点密切相关时(比如,一起出现、变更或消失),将它们放置在一起就是非常有意义的。因此,将组件特有的样式或行为放到组件标记定义的地方(内聚原则),会使其受益匪浅。另一方面,把松散依赖于特定组件的样式或行为放在一起可能会产生可维护性问题或缺陷(如重复/过时/已消亡/缺失的代码)。理想情况下,Svelte 存储只关注单一内聚行为。
Svelte 存储包含在一个标准 JavaScript 文件中,与 RxJS 的 observable 类似,它们至少暴露了一个.subscribe
接口,调用者可以通过该接口对存储中的值做出反应。存储与应用程序的组件架构解耦之后,就可以独立演进,只需保证接口不变即可。反之,客户端的变化也不必导致存储的变化。
Svelte runes 将为 Svelte 存储提供另一种语法。Svelte 团队认为,runes 是一种更好的替代方案:
现实情况是,随着应用程序复杂性的增长,确定哪些值是反应式的,哪些值是非反应式的将会变得很棘手。[......]如果代码在
.svelte
文件中表现为一种方式,而在.js
中又表现为另一种方式,那么代码的重构就会变得非常困难。例如,如果你需要将某些内容转化到存储中,以便于在多个地方使用它。
[......] 我们发现,当开始实现复杂的事情时,存储 API 可能会变得相当笨重。此外,团队还观察到:
[......]如果超过一定的复杂度,要理解 Svelte 选择何时更新哪些值所带来的复杂性会非常难以处理。提议的 API 依赖于新的
$state
、$derived
和$effect
原语:
除了.svelte
文件之外,这三个原语均可以在.js
和.ts
文件中使用。让开发人员通过更加重量级的语法来明确声明反应式依赖,这样能够避免遗漏或误解这些依赖关系。它还能对编译器进行一系列优化,从而加快应用程序的运行速度。Svelte 团队认为:
Signals 能够解锁细粒度的反应性,这意味着(举例来说)在一个较大列表中,某个值的变化不需要让列表中的其他成员失效。因此,Svelte 5 的速度会超乎寻常得快。
开发人员的早期反应褒贬不一。一位持有怀疑态度的开发人员在 Reddit 上写道:
难以言表!尽管我完全明白它能解决什么问题,但是它给人的感觉并不像我之前喜欢的 Svelte。以前,Svelte 与 vanilla JS 非常接近。
像const
、let
和export
这样的保留字是有意使用的。即便是像onMount
这样的内容,对生命周期稍有了解的人都能轻松理解并使用。甚至在整个 Svelte 中我最喜欢的$:
也会消失。我希望它能够提供可选择性,而不是成为编写 Svelte 的唯一方式。
一位 Vue 开发人员则对新语法丝毫没有感到陌生:
作为在 Svelte 网站上工作过几周的 Vue 开发人员,我对 runes 感觉很熟悉,我喜欢将反应式依赖暴露出来的想法,这样就可以在 js/ts 文件中重用组件逻辑或创建存储。
另一位开发人员总结了新语法的一些重要优点,如下所示:
这确实带来了我一直翘首以盼的两项改进(类型化的 props 以及在组件之外编写反应式代码的更佳方法)。
此外,Filip Tangen还撰写了一篇关于Svelte 5的详细评论,其中考虑到了优势和不足,并提出了一种新的方言(代号为 Pelte)。
Svelte 5 仍处于早期阶段。Svelte 团队警告说:
你还不能在生产环境中使用 Svelte 5。我们目前还处于研发阶段,无法告知何时可以在应用程序中使用它。不过,开发人员可以访问一个预览网站,上面有新功能的详细说明和互动式的练习场所。
原文链接:
Rethinking 'Rethinking Reactivity' - Svelte 5 Introduces Runes
评论