关于前端:Vue-如何去组织大型-SPA-应用架构

5次阅读

共计 2008 个字符，预计需要花费 6 分钟才能阅读完成。

大型应用程序最要害和最具挑战性的方面之一是良好且正当的文件构造。在思考应用微前端将代码库合成为多个应用程序之前，能够遵循一些步骤来改良我的项目级别的架构，并使转换更容易（如果您思考过这条门路）。

本文将介绍如何通过设置性能之间的界线并最大限度地缩小代码耦合和副作用，使代码库更易于了解。

当咱们应用 Vue Cli 生成我的项目的时候，组件构造是扁平的，不遵循任何层次结构。

assets 目录，用于寄存我的项目中的动态资源，如图片，音频，字体，css 款式等。
components 目录，用于寄存一些可复用的组件，整体比拟扁平化的。
router 目录，用于寄存路由配置文件
views 目录，用于寄存页面 Vue 文件
main.ts 文件，文件作为应用程序的入口点，反对 Vue 初始化和插件或附加库的配置。
App.vue 文件，代表应用程序的根组件，充当其余组件的容器并充当主模板。

对于一个小型我的项目来说，这样的文件构造组织看起来没太大问题。然而，对于一个大型项目来说，这种架构很快就会失控。须要某种模块化能力轻松定位给定文件，设置性能之间的边界，并防止组件的严密耦合。

任何大型应用程序都分为多个独立的性能。辨认它们并不总是那么容易和间接，但通过一段时间的教训积攒后会变得更好。让咱们尝试将一个风行的应用程序分成几个局部作为练习。

微博的个人主页上有很多的性能内容。

工夫线是页面的外围，四周有许多性能，如导航、微博创立局部、热搜、感兴趣的人等。

将形成这些性能的所有组件放在同一个文件夹中是不可保护的，并且即便应用 IDE 的疾速查找选项，找到其中一个组件也将十分艰难。

依据我数十年的工作教训来看，更好更全面的文件组织构造应该像下边这张图一样。

assets 目录
components 目录 – 整个应用程序中应用的所有共享组件。
config 目录 – 一些通用的环境配置文件
features 目录 – 蕴含所有应用程序性能。咱们心愿将大部分利用程序代码保留在此处。稍后会具体介绍这一点。
layout 目录 – 页面的不同布局。
lib 目录 – 咱们的应用程序中应用的不同第三方库的配置。
pages 目录 – 应用程序的不同页面
router 目录 – 路由配置
services 目录 – 跨性能共享的一些服务封装。
stores 目录 – 一些共享的性能数据流治理
test 目录 – 单元测试
utils 目录 – 本人写的一些工具办法
types 目录 – TS 的类型申明

默认状况下，Pages 文件夹将用于寄存理论 Router 配置中的具体展现页面。将所有页面放在一处十分有帮忙，但其中的逻辑应放弃在最低耦合度。
为了更好维护性和可扩展性，咱们的指标是将大部分利用程序代码保留在 features 文件夹中。每个性能文件夹都应蕴含给定性能的独立解耦的业务实现代码。
在现实状况下，咱们其实不须要跨 feture 去共享组件，store, services 等这些专用逻辑。但，理论业务开发中需要会千奇百怪各种变动，所以不可避免咱们须要一些全局共享的 store、组件、service 等。但，当咱们须要放入公共复用目录的时候，须要好好思考一下，这么做是否有必要。

正如咱们之前提到的，咱们的大部分业务代码应该位于多个子目录的 features 文件夹内。

所以 features 目录下，须要正当的布局组织，以便于晋升咱们的可维护性。

API – 以后功能模块，所有的网络申请数据前置解决，都在这块实现。
components – 组件层。以后 feature 拆分进去的业务组件。
store – 数据管理。以后 feature 应用的 store
types – 类型申明。
test – 单元测试。
index.ts – 这是该性能的入口文件。它的行为就像该性能的公共 API，并且它应该只导出应该对应用程序的其余局部公开的内容。

上边提到的 Index.ts，就像是该功能模块的索引文件一样。作为该功能模块被内部模块应用的惟一援用入口。

代码示例：

# Bad 🚫 🚫 🚫
import {UserProfile} from '@/features/profile/components/UserProfile.vue'

# Good ✅ ✅ ✅
import {UserProfile} from '@/features/profile'

咱们能够通过配置 ESlint 的规定，来强制在编码过程中应用咱们的举荐写法。ESlint 配置如下：

rules: {
      ...
    'no-restricted-imports': [
      'error',
      {patterns: ['@/features/*/*'],
      },
    ],
    'import/no-cycle': 'error',
    ...
}

面向性能的架构是构建简单我的项目的无效且通过考验的形式。

它容许咱们将代码解耦到独自的模块中，并随着我的项目代码变得更加简单而扩大咱们的我的项目。

你们的我的项目构造是不是也是相似的呢？你有应用不同的模式吗？欢送探讨

正文完