前端开发的玄学之开发的意识流——基座前端开发的玄学之开发的意识流——前言 - 掘金 (juejin.cn) 第一部分：基

第一部分：基座

1. 一个虚拟的项目

为了让文章更有可读性，我们假设要创建一个后台管理项目。当然了，这个项⽬只是作为⼀个开题的引⼦，后续并不会有太多的讨论。切记，这是⼀个⽞学的项⽬

2. 选取合适的开发框架

是选择Vue？还是React？还是Angular？或者jQuery？我个人做了多个Vue项目，做过一个React项目。对Angular不熟悉，对jQuery也不熟悉。

因此，我选取框架的时候我只考虑了一个点：

我熟悉的，我能把控的

从内心来讲，我个人觉得React对我开发概念的提升最大。我更喜欢React一些。我看过Vue与React的官方文档，Vue的文档更像是handbook，React的文档，则徐徐渐进地讲述了一门开发哲学。

通过对React官方文档的阅读，我对个人以前的开发经验进行了各种反省和总结。其中，“React 哲学”——这一章节，对我的影响实在是太大了，它一步一步告诉我怎样去开发一个模块，怎样去设置状态，这在我以前的开发团队中是从来没有过的。我尝试看过别人怎么去写一个模块，尝试去总结别人的“套路”，也去咨询过别人，但是都是一团雾水，没有人（我认识的）总结过这样的文档告诉我：你就按照这个方式去开发模块！因此，我喜欢React开发，我认为更好。

react 优势一：函数式模块开发。

从入行开始，每次找工作都在要求栏上看到，“熟悉单元测试”。我已经做了几十个项目了，也待过了很多家公司，有大有小，团队很少或者基本没有单元测试！

为什么会这样呢？

我想，应该是关注点太多了，需要从CSS、JS、HTML这三个层面上来插入各种状态，造成数据（应该说是状态）很难集中在一个地方。由此，很难划分“单元”，很难集中管理入口。Vue的SFC，表面上很独立，但是在SFC内部，数据还是被分散在template、script、style这些地方。感觉一个SFC，更像是一个“类”——独立，但是可测试性没有函数高。我也在项目中写过单元测试，发现类的单元测试很难写，函数的单元测试更容易一些。我认为类是自带副作用的，一般情况下，它需要处理内部的状态；类的静态函数也面临着“静态”的副作用。只有纯函数，才更安全，更纯粹。我想到了ESLint有个配置，它可以将没有引用外部状态的函数，提升成一个static函数。

a. 个人在做项目的时候，由于“单例”的存在，很多模块很难被测。它会破坏模块的“纯度”。让测试对象的返回结果会受制于外部单> > 例提供的状态。

b. 自己开发一些工具的时候，也会尽量使用函数，而不是类。工具是为了做运算，而类本身属性需要对很多状态进行配置，才能让函数有正确的返回，让关注点扩散。

react 优势二：单向数据流

天然的，我们人类的大脑对于处理流程化的东西更有感知；而对于一些结构的事物，容易陷入纠结。比如，我们描述大象装冰箱，习惯说：第一步，打开冰箱门，我们定义这一步叫做A；第二步，把大象装进去，叫做B；第三步，关上冰箱门叫做C。我们内心就会将这三步概括为ABC。假如，流程变成了双向的，你做的每一步都可能影响到其他步骤，简单从A到B，都有可能变成ABA、ABAB、ABABA……状态产生了纠缠，更别提再多一步C了，ABC、ABABC、ABABCABC……这一段描述略显抽象，我想表达的意思是，当状态方向不确定的时候，很容易出现问题，不可预知的问题。

a. 我想到了全局事件。有一个观点，当项目变大的时候，全局事件会变得非常不可控。我们很难知道事件是从上到下，还是从下到上，我们很难把握处理事情的方向。

b. 我们喜欢事情的发展是线性的，这样才更好地建立预期。线性的，是有方向的。

c. 开车的时候，你希望路上有很多红绿灯吗？

react 优势三：一次更新，渲染全部

React认为UI = f(DATA)，UI是数据的映射。那么，数据变了，UI就应该变化。假设UI真的就如这句话这么简单，好像前端开发就突然变得傻瓜，只需要关注数据就行。真的是这样么？

给你五分钟思考。

好了，你思考结束了。不知道你有没有发现现在项目的UI已经变得越来越复杂，更新逻辑也变得越来越复杂，你可能想通过各种方式，既要开发速度快、又要执行效率高、又要安全、又要性能，更新渲染的逻辑会越来越复杂。

比如Vue的模板，做了各种优化来提升渲染效率。

你真的关心这些么？你遇到这样的场景多么？我是不怎么关心的，我遇到的大多数UI问题并不在于是不是“脏”渲染逻辑，我希望它的执行步骤越少越好，不要让我关注太多的细节。我需要只关注“接口”（入口），不介意它绘制的方式。它的这个思路，也影响了我在对接后端接口的思路，以前总是拿req数据跟res数据进行各种拼拼凑凑，心里憔悴，假设req与res分离，不要你来req+res各种适配视图，这样一来心智成本更低了。

react 优势四：领跑者

开发思路多少年了，都止步不前，当React出现后，各种编程思想层出不穷。

小结

虽然以上种种，但是，

我选择了Vue3。因为我熟悉，我能掌控。

小思考：在我写的前端项目中，UI很少遇到性能瓶颈，或者说，遇到的所谓性能瓶颈，我都能解决。什么“池化技术”，什么“防抖节流”，什么“分帧渲染”，这些解决了99%的前端性能问题了。所以什么框架的是否适合大小项目，对我来说几乎无感。

3. 选择合适的UI框架

选取合适的UI框架这一步可不是简单的选取UI框架，或者说，我们需要做的更多。假设，我们不使用UI框架，单单实现一个“按钮”就非常麻烦。之前做的游戏项目，实现一个按钮看起来非常简单，有这些功能：

有hover效果；
可以自由缩放；
鼠标移入需要变成小手；是不是看起来每一个功能都非常简单？来看实现：
两张图片，一张静止态，一张hover态，当鼠标移入后使用hover态；
使用9宫格来处理；
禁止电脑自带的鼠标箭头显示，鼠标移入后，使用一张“手”来替换鼠标箭头；

真的实现了一个“完美”的按钮了么？即使是在当前我们不增加需求，不“增加”（哈哈哈）其他交互的情况下，当按钮按下时候的样子，按钮变得非常小的时候，鼠标移开按钮以后，这些情况貌似也没考虑哦！！！

甚至我在做后台管理系统时候，一个下载按钮，让我来实现，我都没时间全部搞定，只能用UI 库提供的。

上面说的感觉有些跑题了，我想说的是：

UI框架=UE+UI——一定要切记这句话！

碰到过一个项目，设计师在设计的时候参考的是Ant Design框架制作的一个项目，而前端选择的UI框架确实 Element UI。造成开发人员在还原UI稿、还原交互体验的时候，基本无法按期完成，或者，在整个项目周期里面，都不会完成。出现这种情况，很让人痛心。然后别的岗位同学就会给老板打小报告：前端同学能力不行，设计还原度很差。

我们需要跟设计同学、产品同学明确一个原则：不要创造组件，不要创造交互。将组件跟交互的选择权，交给前端同学，或者，交给框架。

这个原则很难实现，UI、产品同学他们不了解前端，或者说是不了解所谓的“现代前端”。当然，你要是问我这里的“组件”的范围，我也无法具体描述，我只能说：UI库里有什么，我们就用什么，组件库里的组件怎么交互的，我们就怎么用。

这里，我选择了Ant Design。因为设计师参考的就是一个Ant Design的项目。

同志们，切记，不要创造组件，不要创造交互！设计师个人的“最强大脑”，比不上Ant Design团队千锤百炼总结的设计指导。

项目中，还有很多ECharts图表。啊？这个跟UI框架有什么关系呢？有很大的影响！ECharts的各种UI是独立的一套体系，是用canvas或者SVG绘制的，跟DOM组件不是一套东西！因此，我们也要再加一些约束，或者原则。切记啊，ECharts的UI可是跟Ant Design能控制的UI，不在一个容器里面。

总结下来，当前的UI主要是两种：DOM的UI，ECharts的UI，那么，我们的原则就要再补充一下了。

不要创造组件，不要创造交互，能用默认就用默认；
ECharts的UI体系跟Ant Design的体系，要分离；

整体来讲，我们一定要降低UI体系带给我们的心智成本，保证我们做项目的时候可以不需要太多思考，通过简单布局，拿来即用，就可以实现UI的还原。