关于模块化的再次思考

Posted on

之前关于模块化只是commonJS、amd、es6模块化这些，今天受一篇文章 — 每日优鲜供应链前端团队微前端改造 - 掘金 的启发，发现之前对模块化的概念只是局限于单个项目内，模块化应该上升至项目 — 微前端的诞生背景。

想起之前做后台时有个需求是要接入另外个系统的某些功能，当时能想到的最简单的解决方案是嵌入iframe，打开别的系统，其中鉴权完全由后端控制，体验不完美，因为iframe内的dom无法控制。如果项目模块化，是否会有更好的接入方案。

下面再捋下模块化相关概念。

一般说模块化，都是js模块化。

浏览器由HTML、CSS、JS组成开发，页面渲染DOM，出现JQuery，可以很好的控制DOM API，暴露 window.$ ，代码多了后就会有 使用命名空间拆分 或 模块化拆分 的需求

单用命名空间，这样做有很多问题，其中包括：
• 命名空间冲突，两个库可能会使用同一个名称，例如 Zepto 也被放在 window.$ 下；

  • 无法合理地管理项目的依赖和版本；
  • 无法方便地控制依赖的加载顺序。

当项目变大时这种方式将变得难以维护，需要用模块化的思想来组织代码。

JS 模块化

发展： CommonJS -> AMD -> ES6模块化

commonJS

同步加载、前期Node.JS 采用

采用 CommonJS 导入及导出时的代码如下：

1
2
3
4
// 导入
const moduleA = require('./moduleA');
// 导出
module.exports = moduleA.someFunc;

AMD

异步加载、浏览器支持

1
2
3
4
5
6
7
// 定义一个模块
define('module', ['dep'], function(dep) {
  return exports;
});
// 导入和使用
require(['module'], function(module) {
});

ES6标准化

1
2
3
4
5
6
7
8
// 导入
import { readFile } from 'fs';
import React from 'react';
// 导出
export function hello() {};
export default {
  // ...
};

ES6模块化是同步还是异步？？

CSS模块化

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
以 SCSS 为例，把一些常用的样式片段放进一个通用的文件里，再在另一个文件里通过 @import 语句去导入和使用这些样式片段。

// util.scss 文件
// 定义样式片段
@mixin center {
  // 水平竖直居中
  position: absolute;
  left: 50%;
  top: 50%;
  transform: translate(-50%,-50%);
}
// main.scss 文件
// 导入和使用 util.scss 中定义的样式片段
@import "util";
#box{
  @include center;
}

微前端

微前端 由ThoughtWorks 2016年提出，将后端微服务的理念应用于浏览器端，即将 Web 应用由单一的单体应用转变为多个小型前端应用聚合为一的应用。

microFrontendmicroFrontend

一般思路为 为对原项目最小入侵，需新建一个项目作为汇总项目，原业务项目作为子项目。

可以理解为一个容器，不包含任何业务，除了提供“子项目”注册、合并功能外，还可以提供一些系统级公共支持，例如： 用户登录机制 菜单权限获取 全局异常处理 全局数据打点

子项目对外输出不需要入口HTML页面，只需要输出的资源文件即可，资源文件包括js、css、fonts和imgs等。

个人暂无实际经验。就比瞎贴了。

留坑。

参考文档

© 2019 lvbin's Blog All Rights Reserved.
Theme by hiero