路由守卫和路由懒加载和两种模式

路由守卫

路由守卫：

1. 是什么

​ 在路由跳转之前、之中、之后触发的钩子函数（类似于生命周期）

2. 分类

​ 全局守卫

	 -- beforeEach：全局前置守卫：在切换路由之前触发

​ – beforeResolve：全局解析守卫：之中

​ – afterEach：全局后置守卫：之后

​ 路由守卫 beforeEnter

const router = new VueRouter({
  routes: [
    {
      path: '/foo',
      component: Foo,
      beforeEnter: (to, from, next) => {
        // ...
      }
    }
  ]
})

​ 组件守卫 :

• beforeRouteEnter
• beforeRouteUpdate (2.2 新增)
• beforeRouteLeave

全局前置守卫

const checkList = ['/trade', '/pay', '/center'];
/**
 * @params to 要去的路由对象($route)
 * @params from 从哪来的的路由对象（当前路由对象）($route)
 * @params next 是一个函数：跳转到哪个路由的方法  
 				比如：要去to这个路由 next()	
					 要去登录路由 next('/login')
 */
router.beforeEach((to, from, next) => {
    if (checkList.indexOf(to.path) > -1 && !store.state.user.token) next({ name: "login" });
    else next();
})

路由懒加载

正常打包：

• 其中chunk文件是node_modules生成的。

• app文件是自己写的源代码。

使用路由懒加载打包：

正常打包，会将所有的组件打包成一个。会造成文件过大，影响页面加载。如果能把不同路由对应的组件分割成不同的代码块，然后当路由被访问的时候才加载对应组件，这样就更加高效了。

结合 Vue 的异步组件和 Webpack 的代码分割功能，轻松实现路由组件的懒加载。

首先，可以将异步组件定义为返回一个 Promise 的工厂函数 (该函数返回的 Promise 应该 resolve 组件本身)：实现按需加载组件

const Foo = () => Promise.resolve({ /* 组件定义对象 */ })

第二，在 Webpack 2 中，我们可以使用动态 import语法来定义代码分块点 (split point)：

import('./Foo.vue') // 返回 Promise

1.定义一个能够被 Webpack 自动代码分割的异步组件。

const Foo = () => import('./Foo.vue')

把组件按组分块

把某个路由下的所有组件都打包在同个异步块 (chunk) 中。只需要使用 命名 chunk，一个特殊的注释语法来提供 chunk name (需要 Webpack > 2.4)。

const Login = () => import(/* webpackChunkName: "Login" */"../views/Login");
const Home = () => import(/* webpackChunkName: "Home" */"../views/Home");
const Register = () => import(/* webpackChunkName: "Register" */"../views/Register");

Webpack 会将任何一个异步模块与相同的块名称组合到相同的异步块中。

两种模式

• hash 模式

  • 路径带 # ，
  • 缺点： 没有办法使用锚点功能；不美观
  • 优点：兼容性较好 ie8
  • 原理：跳转路由： window.location.hash
    监视路由：window.onhashchange 事件

• history 模式

  • 路径不带 #
  • 优点：可以使用锚点功能； 美观
  • 缺点：兼容性较差 ie10
  • 原理：跳转路由：window.history.pushState
    监视路径：window.onpopstate 事件
    不过这种模式要使用好，还需要后台配置支持。因为应用是个单页客户端应用，如果后台没有正确的配置，当用户在浏览器直接访问 http://oursite.com/user/id 就会返回 404。
    所以，要在服务端增加一个覆盖所有情况的候选资源：如果 URL 匹配不到任何静态资源，则应该返回同一个 index.html 页面，这个页面就是你app 依赖的页面。
    问题：history 模式出现 404 问题
  • 原因：开发服务器只处理 /根路径请求，别的路径是处理不了，所以访问 /home 就会出现 404
  • 解决：
    开发模式：

   devServer: {
            historyApiFallback: true, // 一旦请求404，就默认返回index.html页面
        },

		上线模式：nginx

 location / {
          try_files $uri $uri/ /index.html;
        }

问题： hash模式不出现 404 问题
因为hash 模式的路径都在 # 后面 ，而 # 后面的参数发送请求是不会携带的，所以每次请求地址都是/ ,所以就不会出现404