Day15 - 守护你的状态转移 : Guard

我们目前所学到的状态机已知，我们能透过 transition 限制状态转换的路径

对的 state 碰上对的 event ，才能转移状态(transition) and ...?

但现实情况下，很常有可能是，就算已经对的 state 跟 event 了，你还是希望加上某些条件或者判断才能转移状态。

比如说开发一个电子报新闻後台，假如一篇新闻的生命周期需要经过『草稿』、『审稿中』、『发布』、『下架』等，我们可以根据此设计成一个状态机。

没错！理想的情况下，一篇新闻从 『审稿中』 → 『发布』时，遇到「审核通过」的事件时，的确应该将新闻的状态转移到发布。

但...，现实情况很常会希望，做更进一步的限制或检查。比如说，只有相关权限人士执行这个操作才有效，或是必须经过特定检核才能转移到发布的状态...。

这时你就需要 Guard 在进入下一个状态前，作为守卫，进行检核判断。

以下图为例，一组登入的状态图，初始状态是登入中，带有一个资料储存「登入错误的尝试次数：Tries」，当 [Logging in] 要转移到 [Logged in] 时，会遇到一个事件 [Valid Entry] ，同时还有一个 Guard 是 Tries 的次数要小於 3 ，当使用者的每次登入失败时，Tries 会被加一，当 Tries 达到3时，就会转移到 [Login Denied] 的状态。

另外一组例子，一个水瓶或是马克杯的状态

一开始是『空的』，有「装水」这个事件，每次要装水时，都会当前水量 + 预计倒水量，有没有超过容器最大容积

「装水」可以一次装满，转移到『满水位』的状态；或是每次都装一点，转移到『有部份水量』的状态

但每次「装水」事件都会检查容量够不够。

最後『满水位』时，配上「封盖」的事件，可以把我们的水瓶或者是马克杯『盖上』

在这边我们也可以稍微猜想一下 Guard 程序面的实作有哪几种可能，可能会是个储存 boolean 值的变数，可能是个会回传你 true / false 的预测函式，也有可能像 JSON config 的样貌。

小结

Guard 也是用来解决状态机在现实世界中可能遇到的问题，当你有想要做什麽限制、检查，才能进到下个状态的话，你可以使用 Guard

参考资料

https://statecharts.dev/glossary/guard.html
https://xstate.js.org/docs/guides/guards.html
https://sparxsystems.com/resources/gallery/diagrams/images/state-machine-diagram-transition-guards-and-effects.png