摘要：但是前端目录结构笔者认为应该对于页面和组件继续细分。举个列子当项目较大时目录里存在将会非常之多。所以，后端这种按职能划分的目录结构虽好，但用于前端也不是最合适的方案。
为什么需要前端专属的项目结构
这里说到目录结构，想必不少程序员会想到按职能分目录吧！以下所提的目录结构为单页面目录结构
以下面这种为例[按职能划分]
├──src │ ├──view //页面 │ ├──utils //JS工具库 │ ├──api //api接口 │ ├──style //style │ ├──config //配置 │ ├──model //model层其实是redux或vux文件 │ ├──component //组件 │ ├── App.vue // 入口页面 │ ├── main.js // 入口 加载组件 初始化等 │ ├── assets // 主题 字体等静态资源 ├── index.html // html模板 └── package.json
其实该目录结构完全没问题,按职能划分结构非常清晰,api放api,静态资源放assets里等等。但是前端目录结构,笔者认为应该对于页面和组件继续细分。
举个列子当项目较大时,api目录里存在api将会非常之多。大致效果如下图:
该图为笔者某个项目的api结构图,虽然笔者按照某个约定api文件名==view里对应的页面组名.但是真正维护起来有时会遇到这么两种常见情况.
1.删除页面：你将删除pages/carts[购物车页面]里的某个页面,但是问题来了你不确定api/carts[购物车api]哪些api才是不用的,其实没用到的有些IDE会提示。
2.复制移动组件或页面: 比如你想复制组件,由于划分颗粒度不够细,你又一次面临该组件对应什么api和什么静态资源,这么移动复制时只能靠猜了= =
其实出现上面问题,就是该种按职能划分的方法不太适合前端。如果你仔细想想前端页面的删除逻辑,你就会知道我们一般会去做删除或废弃的单位就是页面或组件,所以笔者前端目录应该对于页面和组件继续细分
这里在扯远点,不知各位看官老爷是否记得MVC框架，这个衍生于后端思维的前端框架。为什么会被MVVM框架逐渐取代? 原因就是MVC这种框架不适合前端这种频繁需要数据和页面组件联动的场景,因为前端不仅仅是管好数据并渲染这么简单,而是要应付各种数据变化对应的页面组件变化,而MVVM框架恰能解决该痛点。所以，后端这种按职能划分的目录结构虽好，但用于前端也不是最合适的方案。
目标在按职能划分目录的基础上,再细分到按页面和组件划分目录，做到删除组件时不会牵连到其他组件和页面！不会出现页面删除后，资源还常驻于项目中成为钉子户.
解决方案 示例结构├──src │ ├──view //页面 │ ├──carts //购物车页面 │ ├──component //该页面专用组件 │ ├──model.js //该页面的数据层[redux和vuex文件的细分] │ ├──index.js //该页面的布局文件 │ ├──service.js //该页面用到的api │ ├──index.scss //该页面用到的scss │ ├──utils //JS工具库 │ ├──api //共用api接口【永不删除】 │ ├──style //共用style【永不删除】 │ ├──config //配置 │ ├──model //共用model层其实是redux或vux文件【永不删除】 │ ├──component //共用组件 │ ├──map //地图组件 │ ├──model.js //该组件的数据层[redux和vuex文件的细分] │ ├──index.js //该组件的布局文件 │ ├──service.js //该组件用到的api │ ├──index.scss //该组件用到的scss │ ├── App.vue // 入口页面 │ ├── main.js // 入口 加载组件 初始化等 │ ├── assets // 主题 字体等静态资源【永不删除】 ├── index.html // html模板 └── package.json
这里分为三个级别共用级别,页面级别,组件级别
共用级别这个好理解,就是项目经常会共用到的资源，基本上一旦定下,为了项目稳定就永不删除了。
页面级别│ ├──view //页面 │ ├──carts //购物车页面 │ ├──component //该页面专用组件 │ ├──model.js //该页面的数据层[redux和vuex文件的细分] │ ├──index.js //该页面的布局文件 │ ├──service.js //该页面用到的api │ ├──index.scss //该页面用到的scss
可见围绕该页面各种职能的文件又再建一遍,且都为该页面专用,连组件也是页面专用级别的。
组件级别│ ├──component //共用组件 │ ├──map //地图组件 │ ├──assets //该组件专用图片或icon │ ├──model.js //该组件的数据层[redux和vuex文件的细分] │ ├──index.js //该组件的布局文件 │ ├──service.js //该组件用到的api │ ├──index.scss //该组件用到的scss
可见围绕该组件各种职能的文件又再建一遍,且都为该组件专用。
总结在按职能划分目录的基础上,再细分到按页面和组件划分目录。如此这般,组件想删即删想改即改，副作用更可控!!再也不怕留下钉子户资源啦！
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/114392.html
摘要：但是前端目录结构笔者认为应该对于页面和组件继续细分。举个列子当项目较大时目录里存在将会非常之多。所以，后端这种按职能划分的目录结构虽好，但用于前端也不是最合适的方案。 为什么需要前端专属的项目结构 这里说到目录结构，想必不少程序员会想到按职能分目录吧！以下所提的目录结构为单页面目录结构 以下面这种为例[按职能划分] ├──src │ ├──view ...
摘要：但是前端目录结构笔者认为应该对于页面和组件继续细分。举个列子当项目较大时目录里存在将会非常之多。所以，后端这种按职能划分的目录结构虽好，但用于前端也不是最合适的方案。 为什么需要前端专属的项目结构 这里说到目录结构，想必不少程序员会想到按职能分目录吧！以下所提的目录结构为单页面目录结构 以下面这种为例[按职能划分] ├──src │ ├──view ...
摘要：本文最早为双十一而作，原标题双大前端工程师读书清单，以付费的形式发布在上。发布完本次预告后，捕捉到了一个友善的吐槽读书清单也要收费。这本书便从的异步编程讲起，帮助我们设计快速响应的网络应用，而非简单的页面。 本文最早为双十一而作，原标题双 11 大前端工程师读书清单，以付费的形式发布在 GitChat 上。发布之后在读者圈群聊中和读者进行了深入的交流，现免费分享到这里，不足之处欢迎指教...
摘要：本文最早为双十一而作，原标题双大前端工程师读书清单，以付费的形式发布在上。发布完本次预告后，捕捉到了一个友善的吐槽读书清单也要收费。这本书便从的异步编程讲起，帮助我们设计快速响应的网络应用，而非简单的页面。 本文最早为双十一而作，原标题双 11 大前端工程师读书清单，以付费的形式发布在 GitChat 上。发布之后在读者圈群聊中和读者进行了深入的交流，现免费分享到这里，不足之处欢迎指教...
阅读 1586·2021-11-11 10:59
阅读 2590·2021-09-04 16:40
阅读 3613·2021-09-04 16:40
阅读 2919·2021-07-30 15:30
阅读 1532·2021-07-26 22:03
阅读 3137·2019-08-30 13:20
阅读 2191·2019-08-29 18:31
阅读 406·2019-08-29 12:21
