reusable：前端可复用代码目录结构的设计

前端开发的流程

前端开发的主要流程就是取服务端的数据处理后渲染到本地ui，或者取本地ui的数据处理后发送到服务端，本地可能会保存一份副本。

图中只是简单花了一下主流程，可能涉及到一些store和本地localStorage的交互，组件和具体dom的交互等没有画上。

每一个业务模块大致都是这样的流程，多条业务流程之间肯定是有相似或相同的部分，这部分也就是可以复用的部分。

可复用代码的划分

可复用的代码之间也是不同的，比如是ui层的可复用代码，store层的可复用代码，api的可复用代码或者其他部分的可复用代码。

按照流程这个分类依据，可以分为4部分：

可以复用的代码可能是业务代码，也可能是一段业务无关的逻辑。按照是否业务相关这个分类依据，可以分为2部分：

项目可能使用的是不同的技术栈：vue、angular、react等等。可以复用的代码可能是与具体框架相关的，比如vue的directives，vuex的plugins等或者angular的service等。

按照可复用代码的是否框架相关，可以分为2部分：

这3种分类是从不同维度对可复用代码进行划分的，他们之间有几种组合方式：

按照流程 > 是否业务相关 > 是否框架相关的分类顺序来划分是这样的：

按照是否业务相关 > 流程 > 是否框架相关的分类顺序来划分是这样的：

按照是否业务相关 > 流程 > 是否框架相关的分类顺序来划分是这样的：

当然，3种分类依据一共会有6种组合方式，我只是列了其中3种。

但是项目中我们真的会拆分的这么细么？很少，这是理想状态下的划分。具体分类依据和不同分类依据的顺序与我们的实际场景关系很密切。

比如是否框架相关只有在代码需要跨技术栈复用的时候才会考虑，是否业务相关在可复用代码跨项目的时候会考虑，按流程划分在只需要某一层的可复用代码的时候会考虑。

而且可能我们的划分依据会涉及具体业务，比如用户模块的可复用代码，订单模块的可复用代码等。

顶层目录的设计

一般项目中很常见utils、common、core等目录，其实这些都是可复用代码，只是按照不同分类依据拆分的而已，这些可以合并成一个顶层目录，然后内部再细分。

就像我一直觉得page、components、router这些都是view层代码，应该放在view这个顶层目录下一样。

当然，这也是理想状态下，实际分这么细的不多。 ##我们项目的划分方式

最近在调整目录结构，我的想法是这样的：

首先，我们可以把所有的可复用代码放在一个顶层目录reusable下， 然后再分为ui、store、api、other、common这4个二级目录，ui、store、api、other就直接存放可服用的代码文件就可以了。比如ui层的directives、filters，store层的plugins等。

other下是一些与某一层无关的代码，比如StringUtils，DateUtils等。

之所以这么分是因为我们项目的代码不需要跨项目和和跨技术栈的复用，所以不需要考虑是否业务相关，是否框架相关这两个分类依据，只要按照流程分好类存放就会很清晰了。

总结

前端开发过程中，有一些代码是不同的业务流程所复用的，而且按照不同的分类依据：流程的那一层、是否业务相关、是否框架相关等有不同的划分方式，甚至可以按照具体业务来划分。

顶层目录可以是分散开的utils、common、core等，也可以合并成reusable，然后内部再细分。就像view层的components、page、router一样，细分程度不同。

我们的目录调整时，因为项目特性只需要考虑按流程分类就可以了。当然，不同的项目和场景，分类依据是不一样的，但是整体思路类似。