我非常喜欢现代的前端网络开发。特别是，能够孤立地开发组件，并且能够将DOM元素的显示与JavaScript数据的状态联系起来，这些都是很好的。

但是，我们似乎总是忽略了整个应用程序的显示状态，而只顾着孤立地开发组件。这往往会导致相当糟糕的用户体验--例如，加载指示器掩盖了实际内容，或者多个组件同时显示，而它们显然不应该这样。

为什么这种情况会特别发生在现代前端开发中？

这并不是出于恶意，而是因为复杂性。

在过去，每个页面的加载都是在服务器上进行的，确保所有的数据都被加载，然后再把一个完全成熟的HTML页面发送给客户端。然后，页面将显示在一个非常可预测的状态。我们的用户可能需要等待更长的时间才能看到这个页面，而且它可能是一个不太 "像应用程序 "的体验，但至少页面上的内容都是有意义的。

即使我们开始在每个页面上获得更多的互动内容（想想jQuery的AJAX调用），我们通常也只是在处理应用程序的小片段。因此，你可以合理地在你的头脑中进行动态的上下文。"这一个小部件可能会经历一些加载状态，但页面的其他部分是静态的。"

思考组合学的问题

让我们以另一种方式思考这个问题：如果我有一个静态页面，有一个jQuery AJAX widget，有加载、成功或错误状态，我的页面总共有三种状态组合。但是，如果我有一个React应用，有10个可见的组件，每个组件有3种可能的状态，那么我现在有10^3=1000种状态组合！这对我来说太难了。这实在是太难以理解了。

我们需要一个更好的方法来列举整个应用的可允许的显示状态

我得承认：这篇文章并没有提供任何解决方案，而只是指出了一个问题：我们根本没有一个好的方法来列举我们复杂的应用程序的所有允许显示的状态。如果我们能列举出这些允许的状态，理论上我们就能防止不允许的应用程序状态（通过测试或某种自动检查--想想编译时的类型错误）。当然，列举1000种可能的状态是很荒谬的，但一定有一种方法可以合理地处理这个问题。

如果我们要继续沿着这条基于组件的独立前端开发的道路前进，我们需要在把它们粘在一起方面做得更好。用户在使用我们不连贯的应用程序时的体验非常差，我们欠他们更好的。