基于webpack和npm的前端组件工程化实践方案
2020-02-27 195浏览
- 1.富途web前端组件化实践 TooBug / 富途web前端负责⼈人
- 2.关于 曾就职 腾讯CDC 曾维护 Less中⽂文官⽹网 Grunt中⽂文社区 曾翻译 @TooBug 富途web前端负责⼈人 《SVG精髓（第⼆二版）》 《与⼩小卡特⼀一起学Python》 《JavaScript模式》
- 3.富途组件化 1.前尘往事 2.初试⽜牛⼑刀 3.为伊憔悴 4.灯⽕火阑珊
- 4.后端⼯工程师的产物
- 5.弹窗
- 6.问题 效率 低下 ⽆无法 维护 交互 各异 质量量 不不⼀一
- 7.前端从零到⼆二
- 8.富途组件化 1.前尘往事 2.初试⽜牛⼑刀 3.为伊憔悴 4.灯⽕火阑珊
- 9.组件化⽬目标 模块化 标准化 灵活性
- 10.模块化 • AMD模块化规范 • 开发免构建 • i18n插件 • html/text插件 • 构建打包上线
- 11.模块化
- 12.标准化 Dialog ConfirmBox AlertBox MessageBox Widget init / ⾃自定义结构 onCloseClick / onConfirmClick bindEvent / title / content show / hide / layout / onClose preCreate / onCreate / postCreate
- 13.标准化
- 14.标准化
- 15.灵活性 开放扩展和⾃自定义模板
- 16.组件化⽬目标 模块化 标准化 灵活性
- 17.使⽤用 繁琐 难以理理解
- 18.团队和项⽬目
- 19.问题 构建不不 可控 构建奇慢 跨项⽬目 复⽤用 需要定义结构和样式 开发版本和发布版本不不⼀一致，容易易逻辑不不⼀一致 require.js 仅限项⽬目⽬目录内寻址 优化慢 API冗⻓长且不不规范 发布版本依赖构建配置⽂文件，容易易漏漏配置项 与是否压缩并没有太⼤大关系 按路路径精确寻址 继承过多，难以理理解 发布过程完成构建，反馈不不直观 依赖关系不不透明，⽆无法介⼊入分析优化 ⽆无法与npm配合使⽤用 易易⽤用性 规范性
- 20.富途组件化 1.前尘往事 2.初试⽜牛⼑刀 3.为伊憔悴 4.灯⽕火阑珊
- 21.跨项⽬目复⽤用 • 安装（下载） 升级 • 包管理理 • bower • component • npm
- 22.跨项⽬目复⽤用 • 引⽤用（打包） • 尽可能兼容已有代码 • 跟包管理理⾃自然地结合
- 23.跨项⽬目复⽤用
- 24.跨项⽬目复⽤用 npm install ui-modal --save
- 25.require.js → webpack • 1个⼈人 6个⽉月 2单事故 • 600+ js⽂文件 • 关键点： • 多⻚页⾯面多⼊入⼝口 • require.js插件 • 远程模块 • shim(ueditor/jquery/ plupload/angular)
- 26.组件抽取 • 20+组件迁移到单独的Git仓库 • webpack⽀支持node_modules寻址 • 使⽤用npm引⽤用组件
- 27.组件抽取
- 28.组件抽取
- 29.i18n • webpack-amdi18n-loader • 与require.js i18n plugin⼏几乎⼀一样的⽤用法 • runtime选择语⾔言包 • 根据window._i18n.locale或者html[lang]选择 • ⽀支持AMD/CommonJS/JSON/Coffee
- 30.webpack-amdi18n-loader
- 31.组件开源https://github.com/futuweb
- 32.打包体积 • 同⼀一模块重复打包 • 多个⼊入⼝口⽂文件中的相同依赖 缓存复⽤用 HTTP请求
- 33.pa 压 缩 ck 增 量 压 缩 ck 全 量 15 eb pa 缩 未 压 量 增 缩 压 300 w eb .js ck 全 量 ir e .js 缩 压 未 30 w pa qu ir e .js 0 eb re qu ir e 950 re qu 900 w re 打包速度 1200 1,020 600 300 20
- 34.速度 - 增量量和缓存 • 分治：划模块和⼦子任务 分别缓存打包 • 根据源码分析依赖列列表 • 根据打包后的⽂文件获取依赖列列表 • webpack watch的缓存落地 • 先打包 根据中间状态做缓存过滤 再压缩
- 35.速度 - 增量量和缓存
- 36.速度 - 增量量和缓存
- 37.打包环境 开发机 发布机 环境不不⼀一 模块版本不不⼀一 依赖⾃自觉 影响发布时间 结果⽆无反馈 CPU负载⾼高 ⽣生产环境 downtime 影响负载 安全和运维
- 38.打包环境 开发机 CI 发布机 环境不不⼀一 模块版本不不⼀一 依赖⾃自觉 环境⼀一致 专属运算能⼒力力 邮件反馈 影响发布时间 结果⽆无反馈 CPU负载⾼高 ⽣生产环境 downtime 影响负载 安全和运维
- 39.打包环境
- 40.问题 构建不不 可控 构建奇慢 需要定义结构和样式 API冗⻓长且不不规范 继承过多，难以理理解 跨项⽬目 复⽤用 易易⽤用性 规范性
- 41.问题 需要定义结构和样式 API 冗⻓长且不不规范 易易⽤用性 规范性 继承过多 难以理理解 依赖jQuery 难复⽤用 野蛮发展 缺少规划 从Git安装 semver失效
- 42.团队和项⽬目
- 43.组件2.0 • 全新API设计 • 去除多重继承的设计 • 组件封闭，提供定制化选项 • 全⾯面去jQuery 包装适配多框架 • 私有NPM • 重新规划组件
- 44.组件2.0 • 增删、合并组件列列表 • 落地设计规范 统⼀一交互视觉 • 编写测试⽤用例例 ⾃自动化测试 • 全新⽂文档和展示⻚页 • 使⽤用LessCSS • 全⾯面使⽤用ES2015
- 45.组件2.0 - ⾃自动化测试
- 46.组件2.0 - UI规范
- 47.组件2.0 - 私有NPM
- 48.组件2.0 - 私有NPM • 私有NPM registry.npm.oa.com • 命名空间@futuweb • semver语义化版本 解决组件重复打包
- 49.组件2.0 - API
- 50.组件2.0 - API包装
- 51.组件2.0 - ⽂文档
- 52.组件2.0 - ⽂文档
- 53.富途组件化 1.前尘往事 2.初试⽜牛⼑刀 3.为伊憔悴 4.灯⽕火阑珊
- 54.蓦然回⾸首 2015 webpack npm 2014 require.js 组件规范 2017 组件2.0 2016 打包和构建
- 55.蓦然回⾸首 • 团队的⼯工程化和技术迁移成本⾼高 • ⽅方案会和团队⼀一起不不断成⻓长 • 适合团队现状的⽅方案是最好的⽅方案 • 临渊羡⻥鱼者众 退⽽而结⽹网⽽而寡 • 细节为王 冷暖⾃自知
- 56.灯⽕火阑珊 • 不不断有新的问题出现 • 不不断有新的⼯工具出现 • 组件化和⼯工程化的终点在哪⾥里里
- 57.没有终点 - CSS • 核⼼心问题： • 代码组织和复⽤用 • 避免冲突 • CSS Next ? • CSS modules ?
- 58.CSS Modules
- 59.CSS Modules
- 60.CSS Modules • HTML模板中应⽤用不不⽅方便便 • classNames = require('xx.css');
- 61.没有终点 - 组件⽅方案 • • web components • 兼容性不不好 • 框架集成⽅方案缺失 react / angular.js / vue 通⽤用组件⽅方案 • 原⽣生代码包装 • ngVue(angular.js + vue) • JSX(react + vue)
- 62.npm是终极⽅方案吗
- 63.包管理理和引⼊入 • • 包管理理 • bower和component已死 • jspm呢？ 引⼊入 • ES Modules落地？ • system.js + http/2 ？
- 64.jspm + SystemJS
- 65.配置⼯工程师有归宿吗 Windows Mac / iOS Android Web?
- 66.
