对于大型Web应用程序，最佳Vue-Router做法是什么? [英] What is the best Vue-Router practice for very large webapplications?

问题描述

我必须制作一个具有许多不同模块的Web应用程序(例如todo模块，documents模块以及admin用户的大usermanagement模块).页面总数>100.每个用户的模块访问权限也不同.

I have to make a webapplication with many different modules (like a todo-module, document-modules, and a big usermanagement-module for admin users). The total number of pages is > 100. And the module access is different for each user.

我正在使用 Laravel 和 Vue-router .

但是最佳做法是什么?

1. 创建具有1个大型vue-router的SPA应用程序吗?
2. 对于每个模块，都有一个单独的"SPA"(带有和自己的vue-router)?
3. 还是其他建议...?

推荐答案

来晚了，但我会尝试回答这个问题.这不仅仅是一个架构问题，而不仅仅是路由级别的问题.

Little late but I will try to answer the question. This is more an architectural question than just routing level question.

TLDR::您将需要多种方法.一种方法不合适.

TLDR: You will need a mix of approaches. One approach won't fit.

1.路由模式

首先，您应该确定是否要使用 HTML 5历史记录模式或哈希模式 现在是2018年，我绝对建议您使用HTML5历史记录模式.

1. Routing Mode

First, you should determine if you are going with HTML 5 history mode or hash mode It is 2018, and I definitely recommend that you use HTML5 history mode.

如果您使用历史记录模式，则意味着您的客户端路由器将需要与服务器端路由器同步工作.

If you use history mode, then it means your client-side router will need to work in sync with your server-side router.

我不确定您是否知道这一点，但是微型前端是您要寻找的术语.基本上，这是您的第一线隔离.您应该将您的应用拆分为多个较小的应用.每个应用程序都有其根组件，路由器，模型，服务等.您将共享许多组件(当然，非常大这个词很重要.从字面上看是真的.)

I am not sure if you know this, but micro-frontends is the term you are looking for. Basically, it is your first line of segregation. You should split your app into multiple smaller apps. Each app will have its root component, router, models, services, etc. You will share many of the components (Of course, word very large application is important. And I literally mean it.)

如果您选择继续使用微型前端，则可以考虑单仓库配置 使用Lerna或Builder.

If you have chosen to go ahead with Micro-frontends, then you might consider mono-repo setup using Lerna or Builder.

与微型应用程序无关，您的应用程序应具有一个起点-main.js或index.js.在此文件中，您应该初始化所有单例内容.典型的Vue.js应用中的主要单例实体是 Root Component (根组件)，数据存储，路由器等

Irrespective of micro-apps, your app should have one starting point - main.js or index.js. In this file, you should initialize all your singleton things. Main singleton entities in a typical Vue.js app are Root Component, Data Store, Router, etc.

您的路由模块将与任何组件分离.在该入口文件中导入路由模块并在此处对其进行初始化.

Your routing module will be separate from any component. Import routing module in this entry file and initialize it here.

路由模块应进一步分成较小的模块.使用简单的功能和ES模块来执行此操作.每个函数将负责返回RouteConfig对象.这是它的外观:

Routing module should be further split into smaller modules. Use simple functions and ES modules to do that. Each function will be responsible for returning a RouteConfig object. This is how it will look:

const route: RouteConfig = {
    path: '/some-path',
    component: AppComponent,
    children: [
        getWelcomeRoute(),
        getDashboardRoute()
    ]
};

function getWelcomeRoute(): RouteConfig {
    return {
        name: ROUTE_WELCOME,
        path: '',
        component: WelcomeComponent
    };
}

在路由级别，您应该考虑对模块进行延迟加载.这样可以节省很多字节，无需预先加载:

At route level, you should consider doing lazy loading of the modules. This will save many bytes from loading upfront:

function getLazyWelcomeRoute(): RouteConfig {

    // IMPORTANT for lazy loading
    const LazyWelcomeComponent = () => import('views/WelcomeComponent.vue');

    return {
        name: ROUTE_WELCOME,
        path: '',
        component: LazyWelcomeComponent
    };
}

除非使用Webpack或Rollup等捆绑程序，否则您将无法执行此操作.

You cannot do this unless you use bundler like Webpack or Rollup.

这非常重要 警卫是您应处理授权的地方.使用Vue.js，可以编写组件级路由防护. 但是我的建议是不要这样做.仅在绝对必要时执行此操作.基本上，这是关注点分离.您的路由模块应具备应用授权的知识.从技术上讲，授权存在/适用于路线而不是组件.这就是为什么我们将路由创建为一个单独的模块的原因.

This is very important Guards are where you should handle your authorization. With Vue.js, it is possible to write component level route guard. But my suggestion is to refrain from doing so. Do it only when absolutely necessary. It is basically a separation of concern. Your routing module should possess the knowledge of authorization of your app. And technically, authorization exists/applies to a route than a component. That is the reason, why we created routing as a separate module altogether.

我假设您正在为大型应用程序使用某种数据存储，例如Redux或Vuex.如果要编写路由级别防护，则需要参考Redux/Vuex存储中的数据来做出授权决策.这意味着您需要将存储注入路由模块.最简单的方法是将路由器初始化包装成如下功能:

I am assuming that you are using some sort of data store like Redux or Vuex for the very large application. If you are going to write route level guards, then you will need to consult with data from Redux/Vuex store to take authorization decisions. It means you need to inject store into routing module. The simplest way to do that is to wrap your router initialization into a function like this:

export function makeRouter(store: Store<AppState>): VueRouter {
    // Now you can access store here
    return new VueRouter({
        mode: 'history',
        routes: [
            getWelcomeRoute(store),
        ]
    });
}

现在，您只需从入口点文件中调用此函数即可.

Now you can simply call this function from your entry-point file.

请记住定义默认的全部路由，以向用户显示通用/智能404消息.

Remember to define a default catch-all route to show generic/intelligent 404 message to your users.

由于我们实际上是在讨论非常大的应用程序，因此最好避免直接访问组件中的路由器.而是将路由器数据与数据存储保持同步，例如 vuex-router-sync .通过这样做，您将节省大量的错误.

Since we are really talking about very large application, it is better to avoid direct access to a router within your component. Instead, keep your router data in sync with your data store like vuex-router-sync . You will save the painful amount of bugs by doing this.

您经常会在组件中使用$router.replace()或$router.push().从组件的角度来看，这是一个副作用.而是在组件外部处理程序化路由器导航.为所有路由器导航创建一个中心位置.向此外部实体发送请求/操作，以为您处理这些副作用. TLDR；不要在您的组件内直接产生布线副作用.这将使您的组件坚固且易于测试.在我们的例子中，我们使用redux-observable处理路由副作用.

You will often use $router.replace() or $router.push() within your components. From a component perspective, it is a side effect. Instead, handle programmatic router navigation outside of your component. Create a central place for all router navigation. Dispatch a request/action to this external entity to handle these side effects for you. TLDR; Don't do routing side effect directly within your components. It will make your components SOLID and easy to test. In our case, we use redux-observable to handle routing side effects.

我希望这涵盖了非常大规模的应用程序的所有路由选择.

I hope this covers all the aspects of routing for a very large scale application.

这篇关于对于大型Web应用程序，最佳Vue-Router做法是什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！