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設計應用程序的未來比以往任何時候都更加光明。這篇文章的水平很高，可能留下的問題多于答案。在第二部分中 ，我想更深入地研究將狀態圖與組件一起使用的模式。