js焦点新闻—看一下焦点新闻

大家好，很高兴又见面了，我是"自强不息阿古‬"，由我带着大家一起关注前端前沿、深入前端底层技术，大家一起进步，也欢迎大家关注、点赞、收藏、转发，您的支持是我不断创作的动力。

在开发复杂的用户界面或应用时，开发者需要有效地管理状态的存储、计算、无效化和同步，并且要确保状态能够准确地反映到视图层。处理这样的状态管理任务是非常困难的，因为状态不仅仅是简单的值，还可能包括依赖于其它状态的计算结果，这些计算结果本身也可能是动态计算的。

Signals的主要目标就是为应用状态提供一个易于管理的基础设施，使开发者可以将更多的精力放在业务逻辑实现上，而不是繁琐的细节处理。Signals擅长在复杂的依赖关系中无缝地传递状态变化，提供一种自动化的方式去处理状态管理其它方式无法或难以处理的情况。

而且，Signals不仅在UI上下文中有实用价值，在非UI上下文（如在构建系统中，用以避免不必要的重建）中同样具有实用价值。

我们首先看看Signals是什么以及它存在的意义。我们会深入讨论为什么在用户界面复杂的应用程序中，需要一个有效的处理状态的存储、计算、同步的方法，以及Signals在非UI上下文的应用，比如在构建系统中用以避免不必要的重建。

我们将探讨Signals是如何消除手动管理更新应用程序的需求，为我们提供了一种新的编程模式——声明式编程。我们将解析一些相关示例，说明声明式编程如何根据状态的变化进行自动更新。

比起Signals模式,传统的pub/sub模式在管理应用状态时到底存在哪些问题？我们将分析一段简单的Javascript代码，理解如果不适用Signals而采用传统的方式进行开发时可能会遇到的挑战。

尽管JavaScript或Web平台中没有内置Signals机制，但是双向数据绑定一直是UI框架的核心。然而Signals作为一种反应式方法，已经在多种框架中得到了实现。在这一部分，我们将通过proposal-signals提案深入研究Signals如何在JavaScript中得到实现，并探讨Signals的优越性。

最后，我们会讨论Signals的未来发展方向，包括对HTML/DOM的集成等，并提供一些进一步学习的参考链接，帮助读者进一步理解和掌握Signals。

接下来我们就开始详细讨论每一个部分。

首先，我们需要明确Signals是什么？简单的说，Signals的目标就是提供一个基础设施，用于管理应用状态，让开发者能够专注于业务逻辑，而非繁琐的细节处理。

在构建复杂的用户界面时，我们需要快速响应各种状态的变化。例如，用户的输入，服务器的响应，定时器的触发等。每个状态的变化，可能会影响UI的显示。例如，用户输入变化，可能需要实时显示搜索结果；服务器响应变化，可能需要刷新页面；定时器触发，可能需要更新倒计时。这些状态的变化，都需要通过某种机制来触发UI的更新。这种机制，就是Signals。

Signals不仅仅美化了代码，使它更易读，更具可维护性，而且还提高了代码的执行效率。它通过单向数据流与States进行交互，并关联所有计算和／或副作用以反应新的变更。

得益于Signals的出现，开发者在处理状态相关的业务逻辑时，可以摆脱关注繁琐的细节问题，让我们的焦点更加集中在实现所要解决的问题本身。

对于非UI的上下文，例如构建系统中，Signals同样有很大的应用价值，它可以用来避免不必要的重建，提升了开发的效率。

为了更好的理解Signals，下面我们将深入探讨声明式编程以及它在管理应用状态的角色。

Signals 是支持声明式编程的主要构件之一。它取消了手动管理应用更新，转而采用了一种根据状态自动更新的声明式编程模型。

基于命令式编程，开发者需要一步步编写表示每一个操作过程的代码，告诉机器需要做什么。例如，对某个HTML元素改变属性，需要先获取元素，再改变目标属性。对于复杂应用，需要通过大量复杂的命令来进行细微的状态改变，每一次状态改变都会重新获取元素和更新属性，带来了很多的重复性操作，并且使得整体代码的复杂度大大提高。

声明式编程，就是描述我们想做什么，而非告诉计算机如何去做。这种编程模式，将状态声明为函数或者计算的结果，只要状态的值发生了变化，那么依赖这个状态的函数或者计算的结果也自然就会更新。这种声明式的方法，避免了我们重复的去获取及更新元素。

那么，Signals如何与声明式编程结合，构建出一套全新的，高效的状态处理方式呢？我们接下来将详细解析。

在传统的JavaScript中，我们可能会使用类似下面的方式来处理一个简单的业务逻辑：

在上述代码中，有一个变量counter，我们希望无论counter是偶数还是奇数，都能将其渲染到DOM中，并且每次counter发生变化时，我们使用parity来更新DOM。

这种方式存在一些问题：

• 设置counter的样板代码繁重。
• counter状态与渲染系统紧密耦合。
• 如果counter发生变化但parity没有，比如从2变为4，会进行不必要的计算和渲染。

想象一下，如果我们在处理更为复杂的业务逻辑，那么会增加更多的状态变量，更多的逻辑判断，我们将不得不维护复杂的业务状态树。这种观察者模式简直就是一场程序员的噩梦。

尽管我们可以使用pub/sub模型来解决这个问题，但是它带来了新的挑战：

• 需要精确订阅状态的变化，很难获取准确的时机去订阅和取消订阅。
• 管理订阅和取消订阅边界变得复杂，我们可能需要定义很多复杂的规则去识别。
• 它增加了大量的样板代码，使得管理状态变得愈加繁杂。

好在，我们有Signals，下面我们就来看看Signals如何解决这些问题。

以上代码展示了如何使用Signals来实现同样的功能。你会发现，我们消除了很多样板代码。并且很好地解决了pub/sub带来的问题。实际上，Signals带来了以下优势：

• 自动依赖性跟踪：计算信号会自动发现所依赖的任何其他信号。在创建新的计算信号时，我们不需要在意计算信号的依赖关系。只需要简单地使用已经存在的信号，Signals就会自动识别并追踪依赖关系。
• 惰性求值：计算信号在声明时不会立即求值，而是在明确请求其值时才执行。这意味着我们创建的计算信号，不会因为我们没有使用而浪费计算资源。
• 自动缓存：计算信号会缓存其最后的值，如果我们再次请求这个值而信号值并没有变化，那么就不需要重新计算，而是直接返回缓存的结果，以此来避免不必要的计算。
• 与开发工具的融合：内置信号使JavaScript运行时以及相关的开发工具更好地支持信号的检查。开发者能够更直观的看到信号的变化，以最大程度的提高开发效率。

从上面的简单示例中，我们可以发现，使用Signals可以使我们的代码变得更加简洁明了，易于维护和扩展，提高了开发效率。

Signals的未来显然不会止步于此，它将继续往前发展，目前的前景非常广阔。对HTML/DOM的集成只是它未来可能进行的尝试之一，还有很多其他的可能性等待我们去探索。