组件

应用的界面在顶部显示大的<canvas>元素，在它下面有许多表单字段。 用户通过从<select>字段中选择工具，然后单击，触摸或拖动画布来绘制图片。 有用于绘制单个像素或矩形，填充区域以及从图片中选取颜色的工具。

我们将编辑器界面构建为多个组件和对象，负责 DOM 的一部分，并可能在其中包含其他组件。

应用的状态由当前图片，所选工具和所选颜色组成。 我们将建立一些东西，以便状态存在于单一的值中，并且界面组件总是基于当前状态下他们看上去的样子。

为了明白为什么这很重要，让我们考虑替代方案：将状态片段分配给整个界面。 直到某个时期，这更容易编写。 我们可以放入颜色字段，并在需要知道当前颜色时读取其值。

但是，我们添加了颜色选择器。它是一种工具，可让你单击图片来选择给定像素的颜色。 为了保持颜色字段显示正确的颜色，该工具必须知道它存在，并在每次选择新颜色时对其进行更新。 如果你添加了另一个让颜色可见的地方（也许鼠标光标可以显示它），你必须更新你的改变颜色的代码来保持同步。

实际上，这会让你遇到一个问题，即界面的每个部分都需要知道所有其他部分，它们并不是非常模块化的。 对于本章中的小应用，这可能不成问题。 对于更大的项目，它可能变成真正的噩梦。

所以为了在原则上避免这种噩梦，我们将对数据流非常严格。 存在一个状态，界面根据该状态绘制。 界面组件可以通过更新状态来响应用户动作，此时组件有机会与新的状态进行同步。

在实践中，每个组件的建立，都是为了在给定一个新的状态时，它还会通知它的子组件，只要这些组件需要更新。 建立这个有点麻烦。 让这个更方便是许多浏览器编程库的主要卖点。 但对于像这样的小应用，我们可以在没有这种基础设施的情况下完成。

状态更新表示为对象，我们将其称为动作。 组件可以创建这样的动作并分派它们 - 将它们给予中央状态管理函数。 该函数计算下一个状态，之后界面组件将自己更新为这个新状态。

我们正在执行一个混乱的任务，运行一个用户界面并对其应用一些结构。 尽管与 DOM 相关的部分仍然充满了副作用，但它们由一个概念上简单的主干支撑 - 状态更新循环。 状态决定了 DOM 的外观，而 DOM 事件可以改变状态的唯一方法，是向状态分派动作。

这种方法有许多变种，每个变种都有自己的好处和问题，但它们的中心思想是一样的：状态变化应该通过明确定义的渠道，而不是遍布整个地方。

我们的组件将是与界面一致的类。 他们的构造器被赋予一个状态，它可能是整个应用状态，或者如果它不需要访问所有东西，是一些较小的值，并使用它构建一个dom属性，也就是表示组件的 DOM。 大多数构造器还会接受一些其他值，这些值不会随着时间而改变，例如它们可用于分派操作的函数。

每个组件都有一个setState方法，用于将其同步到新的状态值。 该方法接受一个参数，该参数的类型与构造器的第一个参数的类型相同。