Day17 - XState 说为什麽可以选择 XState？ft. 说文解字官网亮点

身为开发者，每次规划、开发都面临无数的判断、种种的选择，为什麽要学这个、为什麽要导入那个？
我们最害怕的冒然导入新东西进一个专案，然後 GG～

尤其是新东西一出来、潮潮跟风学一下、玩一下可以，但是要导入正式的专案要考量到的因素就很多
包含这种 Pattern, Practice 是不是经过时间的验证？是不是主流？适用的情境是什麽？学习门槛高不高等等...

今天想藉由官网首页的关键字，来提供更多资讯，协助大家决定是否导入这个套件，带大家知道为什麽可以选择 XState

透过跟大家分享 XState 官网上半部介绍的 3 大关键字
Finite State Machine, State Chart 以及 SCXML，一起稍微认识一下这个 library 能带来什麽？

Finite State Machine 就是指早前介绍到的 数学 计算模型 (Model of computation)

计算模型：描述了如何根据一组输入值计算得出输出值，也包含了负责运算、储存和通讯等结构的具体组织方式。它可以用於测量一个演算法在时间和/或空间上的复杂度。通过计算模型的抽象化总结，我们可以分析出演算法的效能，而避免在具体程序层面，被不同的技术和实现方式造成的效能差异所误导。 by wiki

也就代表 FSM 一词，比较属於概念面、抽象层次比较高，比较专注在数学、理论上，最後实际底层的实作也是依赖各家的作法。

Finite State Machine 理念及简易实作的部分在前面已经有许多了，在此就不多加着墨。

State Chart 这也是我开赛前相当无感得地方，每次只会想说 State Chart 不就是 State Diagram 、把状态机画成图而已， 每次点那个 link 都给我跳出一篇 1984 年，全英文的 paper，真心傻眼。

後来在各式中英文网站以及最後在 https://statecharts.dev/ 阅读出的资料才知道，原来...State Chart 是一位有名的数学家 David HAREL 提出在现实世界的复杂系统可以怎麽用一个不错的视觉表达的形式(A VISUAL FORMALISM FOR COMPLEX SYSTEMS)，简单来说，就是 FSM 的加强版、现实生活版。

（感谢铁人赛让我长大ＱＱ）

SCXML 则更无感，全名是"State Chart extensible Markup Language"，是在我写到将近尾声的快第18天，才大概知道是什麽碗糕（仅片面一点点）。之前看到这种缩写就先忽略了ＸＤＤＤ

简而言之，就是鼎鼎大名的 W3C 组织基於 Harel 的 State Chart 以及 CCXML (全名Call Control XML，asynchronous event-based blah blah blah)，这两个东西，以及现实世界中各种可能的 edge case 去制订出来的规格书及 Markup Language。

这东西大概也早在 (2005 to 2015) W3C 组织 推出 W3C Recommendation 1 September 2015

This document describes SCXML, or the "State Chart extensible Markup Language". SCXML provides a generic state-machine based execution environment based on CCXML and Harel State Tables.

相信官网提出的这三大特色是想要说服使用者（痾～我指开发者），不要看我们 XState 很新而不放心，他其实就是过去非常经典、实用的 State Chart 制作成一个 library 提供 JavaScript 的开发者使用。

从 1984 David HAREL 发展出概念 -> 2005 - 2015 W3C 专家们一系列讨论、思考、辩论想遍许多 Edge Case。

而 Finite State Machine 的概念，甚至比这更早就普遍实作在硬体开发上。

所以 XState ...

所以 XState ，就是 Finite State Machine, State Chart 软件层面的底层实作，并且遵循着 W3C 推出的 SCXML 原则。

相信官网提出的这三大特色是想要说服使用者（痾～我指开发者），不要看我们 XState 很新而不放心，他其实就是过去非常经典、实用的 State Chart 制作成一个 library 提供 JavaScript 的开发者使用。

JavaScript 的开发者也不用担心自己在风口上，用什麽潮潮 Pattern ，哪天退流行，摔死在路边上，或者在旁边哀号「求不要更新，老子学不动了」。

他就是一个很稳、很早就存在、规格也订得很妥当的程序开发模式。

这叫什麽？换汤不换药？啊～不是，我想这叫做经典不败

随着时代的演进、硬体的进步，以及软件复杂度、这边指 JavaScript, Web Application 的复杂度大幅提升，所以感觉很适合导入「状态机」的概念，将复杂的状态变简单、限缩状态及其转移的路径等。

如上述、过去几篇的介绍，FSM 的概念除了在硬体开发上，在软件开发也已存在许久，如游戏软件，试想一个游戏同时有那麽多状态要被记得。

一时找不到来源，FSM 的确适合复杂的状态处理，据说飞机机师在操作的飞航系统，背後也是透过 Finite State Machine 的方式制作出来，试想要运送一群人在高速飞往空中，人命关天、不容闪失啊。所以开发过程要极力避免 Bug、没思考到的例外、及意外发生

Aircraft flight sub-state machine for turns

参考文献

https://xstate.js.org/docs/
https://www.w3.org/TR/scxml/