by Shawn McKay

肖恩·麦凯(Shawn McKay)

如何在JavaScript中直观地设计状态 (How to visually design state in JavaScript)

使用状态机和状态图开发应用程序的路线图 (A roadmap for developing applications with state machines & statecharts)

Why does state management seem particularly tricky in JavaScript? Is it the inherent complexity of modern apps, or just the tools? How do other fields of engineering develop reliable and predictable systems? Is it possible to draw a system and transform it into code, and vice versa?

为什么状态管理在JavaScript中显得特别棘手？ 它是现代应用程序固有的复杂性，还是仅仅是工具？ 工程的其他领域如何开发可靠且可预测的系统？ 是否可以绘制系统并将其转换为代码，反之亦然？

Let’s explore a paradigm shift in state management towards visually designing systems with state machines & statecharts.

让我们探索状态管理向使用状态机和状态图可视化设计系统的模式转变。

概念>库 (Concepts > Libs)

State management has been on my mind for a while now. I’ve experimented with various state management libraries: Flux, Reflux, Redux, Dva, Vuex, Mobx, and also my own.

我一段时间以来一直在思考国家管理。 我已经尝试过各种状态管理库：Flux，Reflux，Redux，Dva，Vuex，Mobx，还有我自己的 。

There’s no point arguing which is the 10x solution. State libs are different flavors with the same ingredients. They are a piece of the puzzle—they make it easier to sync and connect data.

毫无疑问，这是10倍解决方案。 国家图书馆是具有相同成分的不同口味。 它们是难题的一部分，它们使同步和连接数据变得更加容易。

The solutions that require our focus next concern the bigger picture:

接下来需要我们关注的解决方案涉及更大的范围：

We need to get better at planning & designing systems.

我们需要更好地规划和设计系统 。

打破一切 (Break All The Things)

Think of a user interface that you would consider elegant. Something built to withstand a barrage of random user interactions — you know, the kind of unpredictability that occurs when a user pushes a button more times than expected, interacts with inputs in an unexpected order or otherwise leads you to question your faith in humanity. Real life is hard on systems.

想一想您认为优雅的用户界面。 可以抵御大量随机用户交互的功能—您知道，当用户按按钮的次数比预期的次数多，以意外的顺序与输入交互或以其他方式导致您对人类的信念提出质疑时，这种不可预测性就会出现。 现实生活对系统来说很难。

I’ll predict the project you’re thinking of.

我会预测您正在考虑的项目。

Well… you’re probably not thinking of something built for the web, where the philosophy seems to be “move fast and break things”.

好吧……您可能没有想到要为网络构建某种东西，因为这种哲学似乎是“快速行动并打破事物”。

Judging by the frequency of updates, you’re probably not thinking of mobile either.

从更新的频率来看，您可能也没有考虑使用移动设备。

You’re probably not even thinking of something built recently. We don’t necessarily seem to be getting better at building reliable products.

您甚至可能根本没有想过最近建造的东西。 在构建可靠的产品方面，我们似乎不一定会变得更好。

I think I know what you’re thinking of…

我想我知道您在想什么...

Am I right? ….No?

我对吗？ …。没有？

You might not even recognize this as the Sony Walkman of the 1980s.

您甚至可能没有意识到这是1980年代的Sony Walkman。

As a kid, I received a cassette player like this from a friend who had upgraded to a portable CD player. I understand that some younger readers may find the mention of both of these devices unfamiliar — think of the Walkman as an iPhone, but with larger buttons and greater destructive potential. My primary mission: break it.

小时候，我从一位升级到便携式CD播放器的朋友那里收到了这样的盒式磁带播放器。 我了解一些年轻的读者可能会发现对这两种设备的提及并不熟悉-将Walkman视为iPhone，但具有更大的按钮和更大的破坏力。 我的主要任务是：打破它。

I would try all combinations of buttons to see what might happen:

我会尝试所有按钮组合，看看可能会发生什么：

• Try to eject while the tape was fast forwarding
  磁带快进时尝试弹出
• Hold fast-forward and rewind down at the same time
  快进并同时快退

Try as I might, the Sony Walkman held up better than most websites do today.

尽我所能尝试，索尼Walkman的表现要优于当今大多数网站。

工程接口 (Engineering Interfaces)

Electronics like the Walkman withstood the gauntlet of user testing without any capacity to hide or disable elements of the user interface. Any button could be pressed at any time, anything could happen. And yet it seemed unbreakable.

诸如Walkman之类的电子产品经受住了用户测试的挑战，没有任何隐藏或禁用用户界面元素的能力。 任何时候都可以按下任何按钮，任何事情都可能发生。 然而，它似乎牢不可破 。

It led me to wonder:

这让我想知道：

Perhaps electronics offer a better paradigm for how we can build interfaces on the web.

电子产品也许为我们如何在Web上构建界面提供了更好的范例。

What can we learn from the ancient design process of electronics? How can we better engineer applications? Marty, we need to go back to the future!

我们可以从古代中学到什么 电子设计过程？ 我们如何更好地设计应用程序？ 马蒂，我们需要回到未来！

电子与网络 (Electronics & The Web)

Can electronics teach us a better way to create applications in the browser?

电子产品可以教我们在浏览器中创建应用程序的更好方法吗？

Consider that components produced one of the most significant shifts in web development over the past five years. Perhaps there are other concepts we can borrow from electronic engineering?

考虑到过去五年间， 组件是Web开发中最重大的转变之一。 也许我们可以从电子工程学中借鉴其他概念？

As web developers, we’ve had it good. Like. Really good. Found a bug? Deploy an update to your server within the hour.

作为Web开发人员，我们做得很好。 喜欢。 真的很好 发现了错误？ 在一个小时内将更新部署到您的服务器。

Other fields of engineering aren’t so forgiving. A problem in hardware often results in a device going in the trash. Embedded developers must be careful to ensure a firmware update doesn’t drain the battery or crash all existing devices.

工程的其他领域并不是那么宽容。 硬件问题通常会导致设备报废。 嵌入式开发人员必须注意确保固件更新不会耗尽电池或使所有现有设备崩溃。

Web developers have the luxury to be reckless.

Web开发人员拥有鲁ck的奢侈品。

Not to mention, app developers have rarely faced the same resource limitations as the creators of electronic devices. When was the last time your primary focus was performance and memory usage, rather than just making the damn thing work? A threshold of 60 frames per second is a low bar. But the bar is rising as we start building increasingly complex apps to run on less powerful mobile and IoT devices. We are bordering on an engineering problem that low-level engineers have experienced for decades.

更不用说，应用程序开发人员很少会遇到与电子设备的创建者相同的资源限制。 您上一次关注的重点是性能和内存使用率 ，而不是使该死的东西正常工作是什么时候？ 每秒60帧的阈值较低。 但是随着我们开始构建越来越复杂的应用程序以使其在功能不那么强大的移动和物联网设备上运行，这一标准正在上升。 我们正面临着低级工程师数十年来所经历的工程问题。

Constraints breed creativity. Limitations lead to better design.

制约会激发创造力 。 局限性导致更好的设计。

To see how embracing limitations can lead to better design, we’ll need to drive back towards basic state management fundamentals.

要了解拥抱限制如何可以导致更好的设计，我们需要回过头来处理基本的状态管理基础。

是旧/新状态管理基础知识 (Ye Old/New State Management Fundamentals)

The direction of conversations in the web community tends to lean towards NPM packages rather than fundamental computer science principles.

网络社区中的对话方向倾向于NPM软件包，而不是基本的计算机科学原理。

Engineers aren’t asking “which library is better? as much as they’re asking “how do we design a better system”?

工程师没有问“哪个库更好？ 就像他们在问“我们如何设计一个更好的系统”？

We can start with some basic principles of good design:

我们可以从良好设计的一些基本原则入手：

• distinguish between indeterminate data and finite states

  区分不确定数据和有限状态

• limit possible transitions from one state to another
  限制从一种状态到另一种状态的可能转变
• design visually
  视觉设计

I’ll work through these along with my own path, and 8 realizations that followed.

我将按照自己的道路来完成这些工作，并随后进行8个实现。

1.状态！==数据 (1. State !== Data)

In programmatic systems, the difference between state and data is blurry. They both live in memory, and so are treated the same.

在编程系统中， 状态和数据之间的差异是模糊的。 他们俩都生活在记忆中，因此受到同等对待。

In React, state and data share the same name and mechanisms:

在React中， 状态和数据共享相同的名称和机制：

• getting: this.state

  得到： this.state

• storing : this.state = {}

  存储： this.state = {}

• updating: this.setState(nextState)

  更新： this.setState(nextState)

In electronics, there is less confusion over the distinction between state and data.

在电子学中， 状态和数据之间的区别很少引起混淆。

State represents a finite number of modes that the system can be in — often defined by the circuitry itself. For our Walkman, think “Playing”, “Stopped”, “Ejected”. Like a “mode” or “configuration”, state is countable.

状态代表系统可以处于的有限数量的模式-通常由电路本身定义。 对于我们的随身听，请考虑“播放”，“停止”，“弹出”。 像“模式”或“配置”一样，状态是可数的。

Data, on the other hand, is stored in memory with a nearly infinite set of possible settings. For our Walkman, think of the track that is playing, “Song 2”. Data, like music, may have infinite possibilities.

数据显示，在另一方面，存储在内存中有几乎无限组可能的设置。 对于我们的随身听，想想正在播放的曲目“歌曲2”。 像音乐一样，数据可能具有无限的可能性。

Whatever this DataLoader component below does, the state can only generate a limited set of views: “loading”, “loaded”, or “error”.

无论下面的DataLoader组件做什么，状态只能生成有限的视图集：“正在加载”，“已加载”或“错误”。

Separating state and data can lead to less confusion, and allows us to construct applications based on finite state machines.

将状态和数据分开可以减少混乱，并使我们能够基于有限状态机构建应用程序。

2.国家是有限的 (2. State is Finite)

Electronics developers have long known that a predictable interface is one with a limited and controlled number of states. Without a controlled number of states, systems become difficult to debug and impossible to thoroughly test.

电子开发人员早就知道，可预测的接口是状态数量有限且受控制的接口。 如果没有受控数量的状态，系统将变得难以调试，也无法进行全面测试。

In a finite state machine, states are explicitly defined. Transitions are the set of possible events you can trigger to move between states.

在有限状态机中，状态是明确定义的。 过渡是可以触发以在状态之间移动的一组可能事件 。

As an example, triggering a transition with the event “STOP” will move the state to “Stopped”.

例如，通过事件“ STOP”触发转换将状态转换为“ Stopped”。

In React, we could define a basic Walkman as having at least two states: “Stopped” or “Playing”.

在React中，我们可以将基本Walkman定义为至少具有两个状态：“已停止”或“正在播放”。

Check out this CodeSandbox.

签出此CodeSandbox 。

In a finite state machine, the system is always in one of the possible configurations. The view has no possibility of being anything but “Playing” or “Stopped”. Testing both can give us confidence the system works the way it should.

在有限状态机中，系统始终处于可能的配置之一。 该视图只能是“正在播放”或“已停止”。 对这两者进行测试可以使我们确信系统可以按预期方式工作。

3.管理状态机的复杂性 (3. Manage Complexity in State Machines)

Let’s look at what happens when we start adding two new states to the state machine example: “Rewinding” & “FastForwarding”.

让我们看看开始向状态机示例添加两个新状态时发生的情况：“倒带”和“快速转发”。

When states are equivalent, they are deceptively easy to add. Each state is like its module that can be developed and tested in isolation. But be careful, state transitions should not always be possible.

当状态相等时，它们看起来很容易添加。 每个状态都像可以单独开发和测试的模块一样。 但是请注意，状态转换不一定总是可能的。

We should worry about uncontrolled transitions between states.

我们应该担心国家之间不受控制的过渡 。

Maybe you caught it. We introduced a bug above. Take a minute and see if you can discover what went wrong.

也许你抓住了它。 我们在上面介绍了一个错误。 花一分钟时间，看看是否能找到问题所在。

4.守卫过渡 (4. Guard Transitions)

It seems the cassette tape is all tangled up as we’ve allowed users to jump between rewinding and fastForwarding without stopping the tape in between.

盒式磁带似乎已经纠结在一起，因为我们允许用户在rewinding和fastForwarding之间跳转，而不必在两者之间停下来。

As a solution, we can add guards to our state transitions. Guards are conditions that must be met for a transition to occur. As an example, we can ensure that the events FASTFORWARD , REWIND , & PLAY can only trigger when the state is “Stopped”.

作为解决方案，我们可以向状态转换添加防护 。 保护是发生过渡必须满足的条件。 例如，我们可以确保事件FASTFORWARD ， REWIND和PLAY仅在状态为“已停止”时才触发。

Unexpected state transitions are bound to happen unless we rethink the way we plan and design our state management.

除非我们重新考虑计划和设计状态管理的方式，否则必然会发生意外的状态转换。

As we add additional states like ejected, we have to think through which state transitions can be allowed and under which conditions. With a Walkman, you can eject the tape by pressing stop while the tape is in the stop mode. To add this functionality, we have to add even more guards and determine which transitions are possible.

当我们添加其他状态(如ejected ，我们必须考虑可以通过哪些状态转换以及在哪些条件下转换。 使用Walkman，可以在磁带处于停止模式时按停止按钮弹出磁带。 要添加此功能，我们必须添加更多的防护，并确定可能的过渡。

The likelihood of unhandled state combinations multiplies as additional states are added. This is not a scalable solution. Each additional state results in a check of all transition guards.

未处理状态组合的可能性会随着附加状态的增加而倍增。 这不是可扩展的解决方案。 每个其他状态都会检查所有过渡防护。

It starts to feel more like state is managing you.

开始感觉就像状态在管理您。

The problem with managing guards stems from the way state is being represented: “Stopped”, “Playing”, “Rewinding”.

管理后卫的问题源于状态表示的方式：“停止”，“比赛”，“倒带”。

The ideal data structure for state is not a string or an object.

状态的理想数据结构不是字符串或对象。

But then what is it?

但是那是什么呢？

5.状态是图 (5. State is a Graph)

The ideal data structure to represent state is often a graph. State graphs, commonly known as state diagrams, provide an intuitive way to design, visualize, and control state transitions at each node.

表示状态的理想数据结构通常是图形。 状态图通常称为状态图 ，它提供了一种直观的方法来设计，可视化和控制每个节点上的状态转换。

This is not new news — electronic engineers have been using state diagrams to describe complex systems for decades.

这不是新闻，电子工程师数十年来一直使用状态图来描述复杂的系统。

Let’s look at an example on the web. AWS Step Functions provide a visual interface for graphing the workflow of an application. Each node controls a lambda — a remote function called in the cloud — with the output of each function triggering the input of the next.

让我们看一个网上的例子。 AWS Step Functions提供了可视化界面，用于绘制应用程序工作流程的图形。 每个节点控制一个lambda(在云中称为远程函数)，每个函数的输出触发下一个的输入。

In the example above, it’s clear to see how a user’s actions move through each step, including possible errors and how to handle them. Adding additional steps doesn’t result in exponential increases in complexity.

在上面的示例中，可以清楚地看到用户的操作如何遍历每个步骤，包括可能的错误以及如何处理它们。 添加其他步骤不会导致复杂度成倍增加。

An engineer might remark how much Step Functions have in common with PLC (Programmatic Logic Controller) Block Diagrams. A designer might remark how much they have in common with workflow diagrams. Shouldn’t the way we design state have more in common with the way we plan applications?

工程师可能会指出步进功能与PLC(程序逻辑控制器)框图有多少共同点。 设计人员可能会指出他们与工作流程图的共同点。 我们设计状态的方式与计划应用程序的方式不应该有更多共同点吗？

6.状态图上的支架 (6. Scaffold on State Graphs)

State graphs become the scaffolding for your application.

状态图成为您应用程序的基础。

As an example, a state graph of our walkman could produce a more visually understandable and approachable representation.

例如，我们随身听的状态图可以产生更直观易懂的表示。

Without delving into code concerning guards, we can tell there should be no possibility to jump from “Rewinding” to any other state but “Stopped”. Rather than outlining all the transitions your interface shouldn’t do, you lay out what it can do. Development shifts from a defensive bottom-up coding approach to a top-down designing approach. This shift alone is 10x.

如果不研究有关警卫的代码，我们可以知道应该没有任何可能从“倒带”状态跳到“停止”状态。 而不是概述界面不应该执行的所有转换，而是列出其可以执行的操作。 开发从防御性的自下而上的编码方法转变为自上而下的 设计方法。 仅此偏移量就是10倍。

State graphs are more intuitive, more accessible to debug, and more able to absorb changes in requirements. Alongside state machines, changes in each state can be isolated from their neighboring states. Not to mention that much of the complex transition “guard” logic can be encompassed in a visually comprehensible format.

状态图更直观，更易于调试，并且能够吸收需求的变化。 除了状态机外，每个状态的更改都可以与其相邻状态隔离。 更不用说，许多复杂的过渡“防护”逻辑都可以以视觉上可理解的格式包含在内。

Unfortunately, state graphs can be a ticking time bomb.

不幸的是，状态图可能是定时的炸弹。

Densely connected graphs don’t scale. Consider what would happen if we added another 4 states to the graph above. Readability reduces and repetition increases, with entangled arrows pointing in all directions competing for space. This spaghettification of a state graph is known as a state explosion.

密集连接的图无法缩放。 考虑如果我们在上面的图中添加另外4个状态会发生什么。 可读性降低，重复性增加，指向各个方向的纠缠箭头争夺空间。 状态图的这种意大利化被称为状态爆炸 。

Luckily, there is a way to reduce the visual complexity of designing complex state graphs using a formalized way of describing systems: let’s explore statecharts.

幸运的是，有一种方法可以使用形式化的系统描述方法来降低设计复杂状态图的视觉复杂度：让我们来研究一下statecharts 。

7.主状态图 (7. Master Statecharts)

I first learned about statecharts from Luca Matteis’ presentation on How to model the behavior of Redux apps using statecharts at the Vancouver React Meetup. The next day at work, I brought up this “new” paradigm for state management, only to find many of my engineering co-workers were already familiar with the concept. I work at an IOT based company alongside many hardware and embedded developers. We’re hiring ;)

我首先从Luca Matteis的演讲中了解了状态图，该演示文稿是如何在Vancouver React Meetup上使用状态图对Redux应用程序的行为进行建模的 。 在工作的第二天，我提出了状态管理的“新”范式，却发现我的许多工程同事已经熟悉该概念。 我在一家物联网公司工作，与许多硬件和嵌入式开发人员一起工作。 我们正在招聘 ;)

The concept of a statechart dates back to 1987 when mathematician David Harel published a paper on visually describing complex systems, such as the below example of a quartz watch.

状态图的概念可以追溯到1987年，当时数学家David Harel发表了一篇关于视觉描述复杂系统的论文，例如下面的石英表示例。

Statecharts are both intuitive and easy to master once you understand the language.

理解语言后，状态图既直观又易于掌握。

Statecharts introduce a variety of new state types:

Statecharts引入了多种新的状态类型：

• initial state — the starting state marked by a dot with an arrow.

  初始状态 -用箭头标记的起始状态。

• nested states — states that have access to the transitions of their parent.

  嵌套状态 -可以访问其父级转换的状态。

• parallel states — two non-touching states represented by dotted lines.

  并行状态 -用虚线表示的两个非触摸状态。

• history state — a state that remembers and can return to its previous value.

  历史状态 -能够记住并可以返回其先前值的状态。

Besides, statecharts can encompass how and when transitions & actions are triggered:

此外，状态图可以包含如何以及何时触发转换和动作 ：

• transition — a function that triggers a state change based on a named event. “Stopped” → transition(‘Play’) → “Playing”

  过渡 —基于命名事件触发状态更改的函数。 “停止”→过渡(“播放”)→“正在播放”

• guard — a condition that must be met for a transition to occur. For example, “play” cannot be triggered if no tape is present, or if the tape is at its end. “Stopped” → transition(‘Play’) [hasTape] → “Playing”. Multiple transitions can be possible, given an order.

  警卫队 -过渡必须满足的条件。 例如，如果没有磁带或磁带在其末端，则无法触发“播放”。 “停止”→过渡(“播放”) [hasTape] →“正在播放”。 给定顺序，可以进行多个转换。

• action— triggers that occur based on a state change. For example, triggering a tape to start playing when the state enters “playing”. Actions may occur `onEntry` and/or`onExit`.

  动作 -根据状态更改发生的触发器。 例如，当状态进入“播放”时，触发磁带开始播放。 动作可能发生在“ onEntry”和/或“ onExit”上。

Rewriting the Walkman example as a statechart removes the redundancy found in the state graph. Notice how there is no longer a need for repetition with “STOP” events. Statecharts are scalable — it’s not hard to add additional parallel states such as “Recording” and “Volume”.

将Walkman示例重写为状态图会删除状态图中发现的冗余。 注意，不再需要通过“ STOP”事件进行重复。 状态图是可伸缩的-不难添加其他并行状态，例如“ Recording”和“ Volume”。

Statecharts are more than just a concept for visually describing applications.

状态图不仅是视觉上描述应用程序的概念。

Statecharts can generate the state machines that underly an application.

状态图可以生成作为应用程序基础的状态机。

You can convert visuals to code, and vice versa. View your application logic as a chart, or draw it.

您可以将视觉效果转换为代码，反之亦然。 以图表形式查看或绘制您的应用程序逻辑。

8.状态图工具 (8. Statechart Tools)

Statecharts offer a promising future for genuinely designing systems — and not just on paper. While tools have been around for other programming languages, JavaScript is just now starting to show a boom in statechart tooling.

Statecharts为真正设计系统提供了光明的未来-而不仅仅是纸上谈兵。 尽管已经有用于其他编程语言的工具，但是JavaScript才刚刚开始显示出状态图工具的蓬勃发展。

C & Java developers have tooling available for coding with and alongside statecharts. As an example, Yakindu Statechart Tools brings together the worlds of visual design and code. I recently learned Yakindu also includes a Typescript code generator.

C和Java开发人员拥有可用于与状态图一起进行编码的工具。 例如， Yakindu Statechart工具汇集了视觉设计和代码的世界。 我最近了解到Yakindu还包括一个Typescript代码生成器 。

The same tooling is finally becoming available for JavaScript as well.

最终，同样的工具也可用于JavaScript。

Sketch Systems provides a way of designing systems in markdown that can then be used to prototype in JavaScript. While Sketch Systems does not yet support actions or guards, I’ve found it very useful for prototyping and testing state charts.

Sketch Systems提供了一种在markdown中设计系统的方法，然后可以将其用于JavaScript原型。 尽管Sketch Systems尚不支持动作或防护 ，但我发现它对于原型设计和测试状态图非常有用。

Sketch Systems allows you to export your charts to XState, a statechart-based JavaScript library with its visualization and clickable state prototyping tool.

Sketch Systems允许您将图表导出到XState ， XState是一个基于状态图JavaScript库，具有其可视化和可单击状态原型工具。

Imagine more advanced tooling within your editor. Imagine your workflow as you toggle between visually designing and manually coding your application logic. It’s worth the work we’ll have to put in as a community to advance the tooling, libraries, and editor plugin’s we want to better support using statecharts.

想象一下您的编辑器中更高级的工具。 想象一下您在视觉设计和手动编码应用程序逻辑之间切换时的工作流程。 值得我们作为社区投入的工作，以改进工具，库和编辑器插件，我们希望使用状态图更好地提供支持。

结论 (Conclusion)

Complexity snuck up on us in the JavaScript community. I don’t think we were ready for it. I’ll admit it took me a long time to get good at planning applications. I’d sketch out a component tree and some state shape. Watch prototypes iterate into production. But how could I be any good at planning applications without a formalized visual language to design state diagrams?

JavaScript社区给我们带来了复杂性。 我认为我们没有为此做好准备。 我承认我花了很长时间才能熟练地规划应用程序。 我画出了一个组件树和一些状态图。 手表原型反复投入生产。 但是，如果没有正式的可视化语言来设计状态图，我该如何擅长计划应用程序？

For a long time, I’ll confess that I approached state management more like a mystifying art. I was unaware that there was much to be learned from other areas of computer science with a long history of building and managing complex systems. I grew to understand that there’s value in looking to the past, as well as looking sideways at the fields of engineering around us.

长期以来，我承认我对状态管理的理解更像是一门神秘的艺术。 我没有意识到，计算机科学的其他领域还有很多值得学习的东西，而它们在构建和管理复杂系统方面有着悠久的历史。 我逐渐理解，回顾过去以及侧眼于我们周围的工程领域是有价值的。

We can learn from engineers who have pioneered and developed decades old solutions for creating complex — yet predictable — systems. We can build upon tools & libraries as an ecosystem to support the visual design of application logic. And we will do it because JavaScript needs all of this.

我们可以向工程师们学习，他们已经开创了数十年的解决方案来创建复杂的但可预测的系统。 我们可以将工具和库构建为生态系统，以支持应用程序逻辑的可视化设计。 我们将这样做，因为JavaScript需要所有这些。

The future of designing applications in JavaScript is looking brighter than ever. This article has all been very high level and likely left more questions than answers. In part 2, I’d like to look more in-depth at patterns for using statecharts with components.

用JavaScript设计应用程序的未来比以往任何时候都更加光明。 这篇文章的水平很高，可能留下的问题多于答案。 在第二部分中 ，我想更深入地研究将状态图与组件一起使用的模式。

翻译自: https://www.freecodecamp.org/news/how-to-visually-design-state-in-javascript-3a6a1aadab2b/