组件的可维护性，谁才是强者

啰嗦一下

今天晚上把我自己写的那个高仿Nest.js的项目改了好多内容，其中最重大的就是加入了一个Nest.js没有、但是Spring有的功能：依赖扫描。

举个例子，看了代码就懂了：

//config.js，就当是一个配置文件就行
const { join } = require("path");

module.exports = {
  entry: join(process.cwd(), "src/main.ts"),
  scan: join(process.cwd(), "src/**/*.ts")
}

// src/main.ts
import "x";
import "y";

// src/test.service.ts
import { Injectable } from "x";

@Injectable
class TestService {}

其中：启动时，启动的是main.ts；

那么，我要如何在main.ts里面拿到test.service.ts中的那个TestService呢？要知道，TestService可是没有使用export关键字的啊！

答案就在依赖扫描的那个config.js中。我在config.js中指定了扫描src文件夹下的所有.ts结尾的文件，所以哪怕main.ts和test.service.ts中没有一点的关联，没有一点的耦合，我都能拿得到；前提是：

• 这个类被@Injectable装饰过
• 这个类在src文件夹里

我不会写Spring，也没了解过Spring是如何实现@ComponentScan注解的，但是他的概念被我用TypeScript实现了出来。

这样的好处是什么呢？就是极大降低了代码的耦合，而且基本上是0耦合，全都是他妈的逻辑！业务逻辑！可维护性，在后端，可以说是相当之高。

于是，引出今天的话题：可维护性。

想到前端娱乐圈…

我突然感觉，前端也是完全可以用Spring这一套的；因为前端最烦的是开发范式。比如在HTML中插内容，在内容中插HTML（就是JSX）这类，开发起来舒服是舒服，但是总有傻逼写出来的JSX嵌套个五六七八层，可维护性低到离谱。

一般人不知道该如何去分组件（当然基础的那些还是知道的，比如header要分组件，footer要分组件等等）；但是一旦上升到比较细节的组件，就是玄学了，难以去分组件，因为不知道分还是不分好。

为啥Vue2能成功？

React成功很简单：背后有一个Facebook。但是Vue为啥能成呢？就是因为Vue是一个简化版的Angular；Angular那一堆概念不是前端er不想学，学不会，而是在那时候确确实实不太适合前端，太过于笨重；而Vue的开发范式相比Angular，就显著不一样：就是模版语法。

采用这个模版语法比ng强在哪里呢？那就是：我们终于可以在一个熟悉的HTML模版里面将一个组件的HTML、CSS、JS全写完，而不是像ng那样分开。

有些人可能就会说了：ng的HTML不是也可以写在JS文件里嘛？嗯，确实可以，但是在注解里面用字符串作为模版，和Vue2的模版语法，哪个范式更好？一目了然了，不必多说。

Hook的可维护性

React组件，新手上阵是有难度的；而且，哪怕你是老手，也不容易写出可维护的代码。特别是出现了Hook这东西之后，写出可维护的代码显得更加难了；Vue3走的也是Hook这条路，这也会导致`范式问题和可维护性问题。

为什么？

原因很简单：东一个状态西一个状态；东一个钩子西一个钩子。这会导致很头疼的问题：组件一大，一冗长，就会很难受；特别是在Vue2身上，社区叫好，但是大中型项目里面还是落得和React一样的下场，甚至比React更严重。

ng有这个问题吗？有，但是比较少，因为ng的概念划分的比较多，诸如依赖注入等后端的概念全都被他搬了过来，复用性高了很多。

以后呢？

既然范式和可维护性做得最🐮的是Spring，那能否把Spring那套搬过来？答案是能。不知道大家有没有用过Vue3的装饰器版本，模版语法+装饰器，那个开发体验，和Spring几乎一模一样，几乎爽到爆炸。可惜可惜，装饰器提案到现在还没下来，要不然Vue3已经上了。

哎…真期待在Vue4里见到它落地，这样就再也不需要Hook这个东西了。到时候，前端说不定能被Vue4大洗牌都说不定。

在我心中，最可维护的前端代码就是装饰器版的Vue。对，它没有JSX那样自由，但是确确实实能让代码做到所有人都能理得清。

有感而发，随便聊聊，阐述想法罢了，各位别在评论区上火。