Web开发可以可以借鉴的那些思想

自己从18年11月份接触Web项目，学习Web开发的一些知识。发现了很多在Android客户端中一些很难接触到的东西。这些东西，更重要的是，我想不是编程语言的API调用，框架如React，Redux的使用，而是在这个开发领域，为了解决该领域特定问题的时候，全球的工程师是如何解决这些问题的，他们底层的思考逻辑是什么？
我们知道Redux好用，解决了状态管理的问题。可是，Web早期，是没有状态混乱的问题的，当然也就没有Redux。后来，随着项目复杂度变高，遇到了瓶颈。于是工程师为了解决特定问题，抽象一层，于是有了Flux，接着Redux集成于它，脱颖而出。
这些逻辑，在其他领域也是可以应用的。这篇文章，就是想初步地思考下，Web开发中，有哪些思想逻辑，是值得我们学习借鉴的。有兴趣不妨一起交流一下，欢迎留言讨论~

Flux的单向数据流

先贴上一张著名的 flux 的单向数据流图。

可能你不了解flux，可能下面的一些概念，你不太了解，没关系，你看看能不能透过陌生的概念，去了解背后的思想。如果能给你在编程中一些设计的启发，就更好啦~

/*
                 _________               ____________               ___________
                |         |             |            |             |           |
                | Action  |------------▶| Dispatcher |------------▶| callbacks |
                |_________|             |____________|             |___________|
                     ▲                                                   |
                     |                                                   |
                     |                                                   |
 _________       ____|_____                                          ____▼____
|         |◀----|  Action  |                                        |         |
| Web API |     | Creators |                                        |  Store  |
|_________|----▶|__________|                                        |_________|
                     ▲                                                   |
                     |                                                   |
                 ____|________           ____________                ____▼____
                |   User       |         |   React   |              | Change  |
                | interactions |◀--------|   Views   |◀-------------| events  |
                |______________|         |___________|              |_________|

*/

在我们开始之前，我们先聊下一 flux 存在的意义以及我们为什么需要它。
假设我们正在构建一个网站应用，那么这个网站应用会由什么组成呢？

1. 模板/HTML = View
2. 填充视图的数据 = Model
3. 获取数据、将所有视图组装在一起、响应用户事件、
   数据操作等等的逻辑 = Controller

这是我们熟知的非常典型的 MVC，但它和 flux 的概念其实是很像的，
只是在某些表述上有些小小的不同：

• Model 看起来像 Store
• 用户事件、数据操作以及它们的处理程序看起来像
  “action creators” -> action -> dispatcher -> callback
• View 看起来像 React view (或者其它类似的概念)

所以，flux 就只是一个新名词么？不全是，但是新名词是很重要的，
因为通过引入这些新术语我们可以更准确地表述各种专业术语。
举一个例子，获取数据是一个 action，一个点击是一个 action，
一个 input 变化也是一个 action 等等。我们都已经习惯了从我们的应用里分发 action，
只是以不同的方式称呼它们。 不同于直接修改 Model 和 View，
Flux 确保所有 action 首先通过一个 dispatcher，
然后再是 store，最后通知所有的 store 监听器。

为了弄清楚 MVC 和 flux 的不同，
我们举一个典型的 MVC 应用的用例：
一个典型的 MVC 应用的流程大致上是这样的：

1. 用户点击按钮 A
2. 点击按钮 A 的处理程序触发 Model A 的改变
3. Model A 的改变处理程序触发 Model B 的改变
4. Model B 的改变处理程序触发 View B 的改变并重新渲染自身

在这样的一个环境里，当应用出错的时候快速地定位 bug 来源是一件非常困难的事情。
这是因为每个 View 可以监视任何的 Model，
并且每个 Model 可以监视其它所有 Model，所以数据会从四面八方涌来，并且被许多源（view 或者 model）改变。

当我们用 flux 以及它的单向数据流的时候，上面的例子就会变成这样子：

1. 用户点击按钮 A
2. 点击按钮A的处理程序会触发一个被分发的 action，并改变 Store A
3. 因为其它的 Store 也被这个 action 通知了，所以 Store B 也会对相同的 action 做出反应
4. View B 因为 Store A 和 Store B 的改变而收到通知，并重新渲染

来看一下我们是如何避免 Store A 和 Store B 直接相关联的。
Store 只能被 action 修改，别无他选。
并且当所有 Store 响应了 action 后，View 才会最终更新。由此可见，数据总是沿着一个方向进行流动：
action -> store -> view -> action -> store -> view -> action -> …

---

观察者模式思想

Flux在实际的场景中，我们需要的是将 action 发送到某个地方，让关心它的人知道发生了什么，并且做出相应的处理。
我们将这个过程称之为“分发 action（Dispatching an action）”。

为了分发 action，我们需要…一个分发函数（=￣ω￣=）。
并且，为了让任何对它感兴趣的人都能感知到 action 发起，我们还需要一个注册“处理器（handlers）”的机制。

由此想到，
Flux中的action就相当于被观察者，
处理器（handlers）就相当于观察者，
而“分发 action（Dispatching an action）”就相当于观察者模式中的“观察，订阅”。

Android客户端开发中，也不乏这样的例子。或许，这也是为什么“观察者模式”能成为最常用的设计模式之一的原因吧~

---

统一数据源

Flux 是一种应用架构，或者说是一种思想，它跟 React 本身没什么关系，它可以用在 React 上，也可以用在别的框架上。Redux 的作用跟 Flux 是一样的，它可以看作是 Flux 的一种实现。我们能从Redux学到了哪些可借鉴的思想呢？统一数据源是Redux的一个特点。

整个应用的 state 被储存在一棵 object tree 中，并且这个 object tree 只存在于唯一一个 store 中。

---

状态管理的动机

随着 JavaScript 单页应用开发日趋复杂，JavaScript 需要管理比任何时候都要多的 state （状态）。 这些 state 可能包括服务器响应、缓存数据、本地生成尚未持久化到服务器的数据，也包括 UI 状态，如激活的路由，被选中的标签，是否显示加载动效或者分页器等等。

管理不断变化的 state 非常困难。如果一个 model 的变化会引起另一个 model 变化，那么当 view 变化时，就可能引起对应 model 以及另一个 model 的变化，依次地，可能会引起另一个 view 的变化。直至你搞不清楚到底发生了什么。state 在什么时候，由于什么原因，如何变化已然不受控制。 当系统变得错综复杂的时候，想重现问题或者添加新功能就会变得举步维艰。

前端开发者正在经受前所未有的复杂性。

这里的复杂性很大程度上来自于：我们总是将两个难以理清的概念混淆在一起：变化和异步。 如果把二者分开，能做的很好，但混到一起，就变得一团糟。一些库如 React 试图在视图层禁止异步和直接操作 DOM 来解决这个问题。美中不足的是，React 依旧把处理 state 中数据的问题留给了开发者。

跟随 Flux、CQRS 和 Event Sourcing 的脚步，通过限制更新发生的时间和方式，Redux 试图让 state 的变化变得可预测。

关于更详细的动机，以及Redux 还是 Mobx如何选择，请见我的另一篇博文。

Redux 还是 Mobx？还有没有更好的方式？

组件化、模块化

Android开发中有一个文件叫AndroidManifest.xml。

每个应用的根目录中都必须包含一个 AndroidManifest.xml 文件（且文件名精确无误）。 清单文件向 Android 系统提供应用的必要信息，系统必须具有这些信息方可运行应用的任何代码。

与此类似，web开发中，也有类似的思想。
比如react-router库中Route的集合, Redux中的Reducer也有类似的组合文件。
同时，React本身也有组件 Components 的说法。

Lint 工具

在做Web开发过程中，总是能看到JSLint和JSHint的身影。于是想看看Android开发中有没有类似的工具，还真有，而且已经集成在了Android Studio中。
使用 Lint 改进您的代码

编程语言的相同性

web开发中，用的最多的除了JSX，CSS，HTML以外，就是JavaScript 了。

ECMAScript 和 JavaScript 的关系

要讲清楚这个问题，需要回顾历史。1996 年 11 月，JavaScript 的创造者 Netscape 公司，决定将 JavaScript 提交给标准化组织 ECMA，希望这种语言能够成为国际标准。次年，ECMA 发布 262 号标准文件（ECMA-262）的第一版，规定了浏览器脚本语言的标准，并将这种语言称为 ECMAScript，这个版本就是 1.0 版。

该标准从一开始就是针对 JavaScript 语言制定的，但是之所以不叫 JavaScript，有两个原因。一是商标，Java 是 Sun 公司的商标，根据授权协议，只有 Netscape 公司可以合法地使用 JavaScript 这个名字，且 JavaScript 本身也已经被 Netscape 公司注册为商标。二是想体现这门语言的制定者是 ECMA，不是 Netscape，这样有利于保证这门语言的开放性和中立性。

因此，ECMAScript 和 JavaScript 的关系是，前者是后者的规格，后者是前者的一种实现（另外的 ECMAScript 方言还有 JScript 和 ActionScript）。日常场合，这两个词是可以互换的。

用的最多的ES6

ECMAScript 6.0（以下简称 ES6）是 JavaScript 语言的下一代标准，已经在 2015 年 6 月正式发布了。它的目标，是使得 JavaScript 语言可以用来编写复杂的大型应用程序，成为企业级开发语言。

ES6 中的新特性是我在开发中用的最多的。

任何人都可以向标准委员会（又称 TC39 委员会）提案，要求修改语言标准。所以，JavaScript也是不断地借鉴其他语言特性，不断地发展。

那些相似的语言特性

1. JavaScript与Kotlin中的模板字符串
2. Dart语言和C++中的模板
3. JavaScript之前只有原型继承，后来引入关键字 class
4. JavaScript的Automatic Semicolon Insertion (ASI, 自动分号插入机制)与Kotlin不需要分号

---

参考

很全的Redux学习资料 Get Start

当然也有中文 Redux 中文文档

腾讯前端大佬建文的一篇文章 浅谈 React、Flux 与 Redux

flux的单向数据流主要参考这里 happypoulp/redux-tutorial

如果你想入门flux，可以看这个 https://blog.andrewray.me/flux-for-stupid-people/

Redux 还是 Mobx？还有没有更好的方式？