基于信号的 API

在 sigmut 中，状态管理是通过以下响应式原语进行的

• State<T>：类似于 Rc<RefCell<T>>，但增加了观察变化的额外功能。
• Signal<T>：类似于 Rc<dyn Fn() -> &T>，但增加了观察结果变化的额外功能。
• effect：一个在相关状态发生变化时再次被调用的函数。

use sigmut::{Signal, State};

let mut rt = sigmut::core::Runtime::new();

let a = State::new(0);
let b = State::new(1);
let c = Signal::new({
    let a = a.clone();
    let b = b.clone();
    move |sc| a.get(sc) + b.get(sc)
});
let _e = c.effect(|x| println!("{x}"));

rt.update(); // prints "1"

a.set(2, rt.ac());
rt.update(); // prints "3"

a.set(3, rt.ac());
b.set(5, rt.ac());
rt.update(); // prints "8"

状态之间的依赖关系将自动跟踪，当发生更改时，将自动触发重新计算。

这种机制是最近的一个趋势，也被其他状态管理库所采用，如下所示

• SolidJS
• Preact Signals
• JavaScript Signals 标准提案
• Svelte runes

"状态变化" 和 "状态计算" 的分离

许多状态管理库通过将状态变化与状态计算分离来简化程序。

在 Elm 中，模型-视图-更新 架构将状态变化（更新）与状态计算（视图）分离。

在 React 中，关于 Components and Hooks must be pure 的规则禁止在状态计算期间进行状态更改。在 React 的 StrictMode 中，状态计算会额外调用一次以确保遵循此规则。

在 SolidJS 中，在状态计算期间做出的状态更改将被 延迟到状态计算完成。

在 sigmut 中，状态更改和状态计算是通过使用 SignalContext 和 ActionContext 来分开的。

• ActionContext：用于状态更改
• SignalContext：用于状态计算

通过要求执行状态更改或状态计算的函数使用相应的上下文，可以清楚地区分状态更改和状态计算，编译器可以强制执行这种分离。

"状态更改和状态计算分离" 通过在状态计算期间将状态视为不可变来简化程序，这与 Rust 的所有权概念类似。内部，sigmut 使用 RefCell，但这种相似性有助于在状态计算期间避免 BorrowError。如果您正在使用许多 Rc<RefCell<T>>，切换到 sigmut 可以导致程序更健壮，BorrowError 的发生次数更少。

易于使用的单线程模型

sigmut 采取单线程模型的原因如下

• 简单且易于处理
• 没有死锁的风险
• 不需要同步，可以即时检索当前值
• 与 async/await 兼容，从而实现多线程的优点
• 能够实现无故障（没有基于过时状态的无关计算）

支持使用 async/await 进行异步操作