前端微服务化解决方案5 - 路由分发

路由分发式微前端

从应用分发路由到路由分发应用

用这句话来解释,微前端的路由,再合适不过来.

路由分发式微前端,即通过路由将不同的业务分发到不同的、独立前端应用上。其通常可以通过 HTTP 服务器的反向代理来实现,又或者是应用框架自带的路由来解决。 就当前而言,通过路由分发式的微前端架构应该是采用最多、最易采用的 “微前端” 方案。但是这种方式看上去更像是多个前端应用的聚合,即我们只是将这些不同的前端应用拼凑到一起,使他们看起来像是一个完整的整体。但是它们并不是,每次用户从 A 应用到 B 应用的时候,往往需要刷新一下页面。 – 引用自 phodal 微前端的那些事儿

模块加载器那一章的示例代码,已经非常充分了展示了路由分发应用的步骤.

在单页面前端的路由,目前有两种形式, 一种是所有主流浏览器都兼容多 hash 路由, 基本原理为 url 的 hash 值的改变,触发了浏览器 onhashchange 事件,来触发组件的更新

还有一种是高级浏览器才支持的 History API, 在 window.history.pushState(null, null, "/profile/");的时候触发组件的更新

// hash 模式,项目路由用的是hash模式会用到该函数
export function hashPrefix(app) {
  return function (location) {
    let isShow = false;
    //如果该应用 有多个需要匹配的路劲
    if (isArray(app.path)) {
      app.path.forEach((path) => {
        if (location.hash.startsWith(`#${path}`)) {
          isShow = true;
        }
      });
    }
    // 普通情况
    else if (location.hash.startsWith(`#${app.path || app.url}`)) {
      isShow = true;
    }
    return isShow;
  };
}

// pushState 模式
export function pathPrefix(app) {
  return function (location) {
    let isShow = false;
    //如果该模块 有多个需要匹配的路径
    if (isArray(app.path)) {
      app.path.forEach((path) => {
        if (location.pathname.indexOf(`${path}`) === 0) {
          isShow = true;
        }
      });
    }
    // 普通情况
    else if (location.pathname.indexOf(`${app.path || app.url}`) === 0) {
      isShow = true;
    }
    return isShow;
  };
}

// 应用注册
export async function registerApp(params) {
  // 第三个参数为,该模块是否显示
  singleSpa.registerApplication(
    params.name, // 模块名字
    () => SystemJS.import(params.main), // 模块渲染的入口文件
    params.base ? () => true : pathPrefix(params) // 模块显示的条件
  );
}

路由分发应用

当 url 前缀,与配置中的 url 前缀保持一致的时候, singleSpa 会激活对应的模块,然后把模块内容渲染出来.

应用分发路由

在模块被激活的时候,模块会读取 url,再渲染到对的页面.

这就是微前端路由的路由工作流程

微前端路由的挑战

Hash 路由

在目前所有支持 spa 的前端框架中,都支持了 Hash 路由. Hash 路由都工作大致原理就是: url 的 Hash 值的改变,触发了浏览器 onhashchange 事件,进而来触发组件的更新. 所有的前端的框架,都是基于 onhashchange 来更新我们的页面的. 当我们的架构使用微前端的话,如果选择 hash 路由,便可以保证所有的前端技术框架的更新事件都是一致的. 所以使用 Hash 路由也是最省心的.如果不介意 Hash 路由中 url 的 # 字符,在微前端中使用 Hash 也是推荐的.

HTML5 History 路由

大家都知道,HTML5 中 History 对象上新增了两个 API (pushState与replaceState). 在这两个新 API 的作用下,我们也是可以做到页面无刷新,并且更新页面的.并且 url 上不需要出现#号. 保持了最高的美观度(对于一些人来讲). 当然现在几乎所有的主流 SPA 技术框架都支持这一特性. 但是问题是,这两个 API 在触发的时候,是没有一个全局的事件触发的. 多种技术框架对 History 路由的实现都不一样,就算是技术栈都是 React,他的路由都有好几个版本.

那我们如何保证一个项目下,多个技术框架模块的路由做到协同呢?

只有一个 history

前提: 假设我们所有的项目用的都是 React,我们的路由都在使用着同一个版本.

思路: 我们是可以这样做的,在我们的 base 前端模块(因为他总是第一个加载,也是永远都不会被销毁的模块)中的 Store.js, 实例化一个 React router 的核心库history,通过消息总线,把这个实例传入到所有的模块中. 在每个模块的路由初始化的时候,是可以自定义自己的 history 的.把模块的 history 重新指定到传入的 history. 这样就可以做到,所有模块的路由之间的协同了. 因为当页面切换的时候,history 触发更新页面的事件,当所有模块的 history 都是一个的时候,所有的模块都会更新到正确的页面. 这样就保证了所有模块与路由都协同.

如果你看不懂我在讲什么,直接贴代码吧:

//Base前端模块的 Store.js
import { createStore, combineReducers } from "redux";

// react router 的核心库 history
import createHistory from "history/createBrowserHistory";

const history = createHistory();

// 传出去
export const storeInstance = createStore(
  combineReducers({ namespace: () => "base", history })
);
// 应用注册
export async function registerApp(params) {
    ...

    // history 直接引入进来,用systemjs直接导入实例
    try {
        storeModule = params.store ? await SystemJS.import(params.store) : { storeInstance: null };
    } catch (e) {
        ...
    }
    ...

    // 跟派发器一起放进 customProps 中
    customProps = { store: storeModule, globalEventDistributor: ... };


    // 在注册的时候传入 customProps
    singleSpa.registerApplication(params.name,
                                () => SystemJS.import(params.main),
                                params.base ? (() => true) : pathPrefix(params),
                                customProps // 应用注册的时候,history会包含在 customProps 中,直接注入到模块中
                                );
}
// React main.js
import React from 'react'
import ReactDOM from 'react-dom'
import singleSpaReact from 'single-spa-react'
import RootComponent from './root.component'

const reactLifecycles = singleSpaReact({
  React,
  ReactDOM,
  rootComponent: (spa) => {
    // 在这里,把history传入到组件
    return <RootComponent  history={spa.customProps.history}/>
  },
  domElementGetter: () => document.getElementById('root')
})

...

// RootComponent
import React from "react";
import { Provider } from "react-redux";
export default class RootComponent extends React.Component {
  render() {
    return (
      <Provider store={this.state.store}>
        // 在这里重新指定Router的history
        <Router history={this.props.history}>
          <Switch>...</Switch>
        </Router>
      </Provider>
    );
  }
}

以上就是让所有模块的路由协同,保证只有一个 history 的用法

多技术栈模块路由协同

问题: 用上面的方式是可行的,但是遗憾的是,他的应用场景比较小,只能在单一技术栈,单一路由版本的情况下使用. 微前端最大的优势之一就是自由选择技术栈. 在一个项目中,使用多个适合不同模块的技术栈.

思路: 我们其实是可以通过每一个模块对外输出一个路由跳转到接口,基于消息总线的派发,让每一个模块渲染到正确的页面. 比如 模块 A 要跳转到 /a/b/c ,模块 a 先更新到/a/b/c路由的页面,然后通过消息总线,告诉所有模块,现在要跳转到 /a/b/c了. 然后其他模块,有/a/b/c这个路由都,就直接跳转,没有的就什么都不做.

我们可以这样做:

// Store.js
import { createStore, combineReducers } from "redux";
import createHistory from "history/createBrowserHistory";
const history = createHistory();

// 对外输出一个to的接口,当一个模块需要跳转界面的时候,会向所有的模块调用这个接口,
// 然后对应的模块会直接渲染到正确的页面
function to(state, action) {
  if (action.type !== "to") return { ...state, path: action.path };
  history.replace(action.path);
  return { ...state, path: action.path };
}

export const storeInstance = createStore(
  combineReducers({ namespace: () => "base", to })
);

export { history };

这是路由跟消息总线的一种完美结合的使用方式,消息总线的潜力还有很多,后续会慢慢说明. 未完待续 …

相关文章

前端微服务化解决方案 1 - 思考

前端微服务化解决方案 2 - Single-SPA

前端微服务化解决方案 3 - 模块加载器

前端微服务化解决方案 4 - 消息总线

前端微服务化解决方案 5 - 路由分发

前端微服务化解决方案 6 - 构建与部署

前端微服务化解决方案 7 - 静态数据共享

前端微服务化解决方案 8 - 二次构建

Demo

前端微服务化 Micro Frontend Demo

微前端模块加载器

微前端 Base App 示例源码

微前端子项目示例源码

微信公众号

本文链接:

https://alili.tech/archive/5ff0b366/

# 最新文章