曹来福的个人网站 - Life Cao's Personal Website

干货

React

Vue

工程化

前瞻

life.caoover 4 years

如何使用Xcode调试web在iOS10.x.x兼容问题（含破解文件）

一、问题概述开发中遇到 iOS10.x.x 版本的兼容问题，找不到古董版本真机，新版 Xcode 里 Simulator 中没有了 iOS10.x.x ，找到方法破解，如下： 1.Xcode配置新建项目后，发现新版Xcode设备里是iphone8，且系统是13.0 或 15.0 使用以下步骤把屏蔽的旧机型和系统显示出来 2.替换Info.plist文件打开终端cd 到如下目录，然后open ./打开当前目录，如图 /Library/Developer/CoreSimulator/Profiles/Runtimes 选中iOS 10.3.simruntime 右键选中显示包内容，打开Contents目录，替换掉Info.plist文件 Info.plist 3.下载此文件，覆盖后，重启（Xcode），还不行，重启电脑，重启大法好重启后，打开Xcode，打开 demo项目选中自己的PROJECT, Target选中你想要的版本，比如10.0，这时候就出现久违的古董机型和系统了 4.配置完成，以后无需打开Xcode，直接选中Simulator即可，Device 会有OS 10.3 二、利用mac Safari浏览器像调试pc一样调试模拟器内的web 步骤跟调试真机很相似，熟悉的同学可略过 1.打开需要调试的模拟器和系统（eg: iphone6 10.3）打开模拟器里的Safari,输入想要调试的web url 2.打开Safari浏览器，并打开"开发菜单" 3.选中"开发"Tab，找到想要调试页面 4.网页检查器出现，调试起来吧

640

life.caoover 3 years

Web Components原生支持的组件化

一、前因十一国庆期间，看到大街小巷的红旗飘飘，于是乎想到，可否用H5做个动画国旗，发现了个有趣的东东，一个html静态文件，出现了一个自定义组件？炫酷的动画，有点撩，很难不想了解它一下点击体验，不慎入坑Web Components。二、 fancy-components 国旗动画的来源 HTML <!DOCTYPE html> <html> <head> <meta charset="UTF-8"> <meta http-equiv="X-UA-Compatible" content="IE=edge"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>fancy-components</title> </head> <body> <fc-china></fc-china> <script type="module"> import { FcChina } from './fancy-components/index.js' // new 就相当于全局注册了这个组件，相当于 Vue 的 Vue.component('FcChina', 组件) new FcChina() </script> </body> </html> fancy-components：直译 - 花式组件库，一个 Web Components** 组件库**。接下来介绍下到底什么是 Web Components吧。三、什么是 Web Components Google一直在推动的浏览器原生组件 ,即 Web Components API。它就是为了解决"组件化"而诞生的，它是浏览器原生支持的组件化，不依赖任何库、依赖和打包工具就可以在浏览器中运行。Web Components 不是一门单一的技术，而是四门技术的组合，这四门技术分别是： Shadow DOM HTML templates Custom Elements HTML Imports（已废弃不再介绍） Shadow DOM和 HTML templates（ and slots）类似 Vue 的 Slot，不作详解，有兴趣的同学可点击上面来自MDN的链接学习。下面就介绍里面最重要的一项技术，同时也是所有浏览器都没有提出反对意见，一致通过的一项技术 —— Custom Elements** （自定义元素）**。四、Custom Elements 基础使用它使开发者能够将 HTML 页面的功能封装为 custom elements（自定义标签），window 全局对象上有一个 customElements 提供自定义元素支持，它包含四个 API： define：注册/定义自定义元素 get：获取自定义元素的构造函数 whenDefined upgrade define 注册组件（自定义元素），不能写成自闭和标签，浏览器会当作起始标签包裹后面的全部内容 HTML <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8" /> <title>Custom Elements</title> </head> <body>  <huo-la-la></huo-la-la>   <script> // 注册组件（自定义元素） window.customElements.define( // 参数1：元素名，必须包含一个短横线，以区分原生元素 'huo-la-la', // 参数2：用于定义元素行为的类（类似 React 中的类组件），必须继承自 HTMLElement class extends HTMLElement { constructor() { super() // custome elements 类中的 this 指向组件本身 console.log(this) this.innerHTML = '<h1>货拉拉</h1>' this.onclick = () => alert('啥车都有') } } ) // 多次注册相同名称的组件会报错: // the name "huo-la-la" has already been used with this registry // window.customElements.define('huo-la-la', class extends HTMLElement {}) </script> </body> </html> get _获取第三方组件的构造函数，用于继承扩展，_给上面国旗案例扩展一个点击事件 HTML <!DOCTYPE html> <html> <head> <meta charset="UTF-8"> <meta http-equiv="X-UA-Compatible" content="IE=edge"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>fancy-components-click</title> </head> <body> <my-fc-china click></my-fc-china> <script type="module"> // 要在服务器环境下运行，建议 http-server import { FcChina } from './fancy-components/index.js' // new 就相当于全局注册了这个组件，相当于 Vue 的 Vue.component('FcChina', 组件) new FcChina() // 获取第三方组件的构造函数，用于继承扩展 const FcChinaConstructor = customElements.get('fc-china') customElements.define( 'my-fc-china', class extends FcChinaConstructor { constructor() { super() this.onclick = () => console.log('自定义点击事件') } } ) </script> </body> </html> whenDefined whenDefined是元素定义后触发的回调，接口返回Promise，通常用于异步注册组件的时候 <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8" /> <title>whenDefined</title> </head> <body> <huo-la-la>加载中...</huo-la-la> <script> // 模拟 JS 代码执行延迟 setTimeout(() => { customElements.define( 'huo-la-la', class extends HTMLElement { } ) }, 2000) // 返回一个 Promise customElements .whenDefined('huo-la-la') .then(() => { document.querySelector('huo-la-la').innerHTML = '货拉拉' }) .catch(err => console.log(err)) </script> </body> </html> upgrade 如果在定义元素之前先使用 JS 创建了元素，则元素实例并不是继承的定义元素行为的类，可以使用upgrade HTML <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8" /> <title>upgrade</title> </head> <body> <script> // 先使用 JS 创建自定义元素 const el = document.createElement('huo-la-la') // 再注册自定义元素 class Huolala extends HTMLElement { } customElements.define('huo-la-la', Huolala) // 返回 false console.log(el instanceof Huolala) // 升级元素 customElements.upgrade(el) // 返回 true console.log(el instanceof Huolala) </script> </body> </html> 五、Web Components 对 Vue 的影响潜看一段Vue和Web Components引入组件的对比 Vue 组件 my-span.vue  <template> <span>my-span</span> </template> <script> export default {}; </script> <style> span { color: purple; } </style> 只需要将它稍微修改一下，它就会变成 Web Components 文件，能够直接在浏览器中运行，不用像vue那么复杂需要node、webpack、loader等打包后，浏览器才能识别。 Web Components组件 my-span.html HTML  <template> <span>my-span</span> </template> <script> // 获取 DOM 元素 const dom = document.currentScript.ownerDocument.querySelector('template').content // 有点像 React 定义组件的写法 class MySpan extends HTMLElement { constructor() { super() this.attachShadow({ mode: 'open' }).appendChild(dom) } } // 注册组件 customElements.define('my-span', MySpan) </script> <style> span { color: purple; } </style> 使用 HTML Imports 在 HTML 页面中引入组件： HTML  <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <title>Document</title>  <link rel="import" href="my-span.html"> </head> <body> <my-span></my-span> </body> </html> 当看到这里的时候，感觉，这不就是跟vue很像，不对，应该是vue跟Web Components很像很像，其实并不是巧合，尤大在创作Vue时，大量参考了Web Components的语法。上文提到HTML Imports已废弃，上文只是为了对比当时跟vue的相似度，加以修改，只需要用js生成dom即可，my-span.html 改为my-span.js // my-span.js class MySpan extends HTMLElement { constructor() { super() this.render() } // 生成 HTML 和 CSS render() { const shadow = this.attachShadow({ mode: 'open' }) const dom = document.createElement('span') const style = document.createElement('style') // dom.textContent = 'my-span' dom.innerHTML = ` <slot>默认内容</slot> <slot name="content">默认内容</slot> ` style.textContent = ` span { color: purple; } ` shadow.appendChild(style) shadow.appendChild(dom) } } // 注册组件 customElements.define('my-span', MySpan) index.html  <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <title>Document</title>    <script type="module" src="my-span.js"></script> </head> <body> <my-span> <h1>默认插槽</h1> <h2 slot="content">具名插槽</h2> </my-span> </body> </html> slot的使用是不是vue也跟Web Components很像。Vue和React的官网也提到了和Web Components的关系，Vue 与 Web Components、在React 中使用 Web Components。六、推荐 Web Components 的一些学习路径本文也参考了如下的文档和博客内容，想深入学习的同学可参考：官方-需梯子 MDN Web Docs Web Component可以取代你的前端框架吗？本文demo的代码包： web-componets.zip 注：使用 ES Modules ，都需要开启一个 Web 服务，使用 VS Code 的 Live Server 插件或者使用http-server。

吐血整理react快速入门精华（二）

3.4 类组件状态 state 3.4.1 定义组件状态类组件除了能够从外部 (props) 接收状态数据以外还可以拥有自己的状态 (state)，此状态在组件内部可以被更新，状态更新 DOM 更新。组件内部的状态数据被存储在组件类中的 state 属性中，state 属性值为对象类型，属性名称固定不可更改。 class App extends Component { constructor () { super() this.state = { person: { name: '张三', age: 20 }, } } render () { return ( <div> {this.state.person.name} {this.state.person.age} </div> ); } } 3.4.2 更改组件状态 state 状态对象中的数据不可直接更改，如果直接更改 DOM 不会被更新，要更改 state 状态数据需要使用 setState方法。 class App extends Component { constructor () { this.state = { person: { name: '张三', age: 20 }, } this.changePerson = this.changePerson.bind(this) } changePerson () { this.setState({ person: { name: '李四', age: 15 } }) } render() { return ( <div> {this.state.person.name} {this.state.person.age} <button onClick={this.changePerson}>按钮</button> </div> ); } } 3.4.3 双向数据绑定双向数据绑定是指，组件类中更新了状态，DOM 状态同步更新，DOM 更改了状态，组件类中同步更新。组件 <=> 视图。要实现双向数据绑定需要用到表单元素和 state 状态对象。 class App extends Component { constructor () { this.state = { name: "张三" } this.nameChanged = this.nameChanged.bind(this) } nameChanged (event) { this.setState({name: event.target.value}); } render() { return ( <div> <div>{this.state.name}</div> <Person name={this.state.name} changed={this.nameChanged}/> </div> ) } } const Person = props => { return <input type="text" value={props.name} onChange={props.changed}/>; } 3.5 类组件生命周期函数在组件完成更新之前需要做某种逻辑或者计算，就需要用到快照 componentDidUpdate(prevProps, prevState, snapshot) {} getSnapshotBeforeUpdate 方法会在组件完成更新之前执行，用于执行某种逻辑或计算，返回值可以在 componentDidUpdate 方法中的第三个参数中获取，就是说在组件更新之后可以拿到这个值再去做其他事情。 getSnapshotBeforeUpdate(prevProps, prevState) { return 'snapshot' } 3.6 Context 通过 Context 可以跨层级传递数据 // userContext.js import React from "react" const userContext = React.createContext("default value") const UserProvider = userContext.Provider const UserConsumer = userContext.Consumer export { UserProvider, UserConsumer } // App.js import { UserProvider } from "./userContext" class App extends Component { render() { return ( <UserProvider value="Hello React Context"> <A /> </UserProvider> ) } } // C.js import { UserConsumer } from "./userContext" export class C extends Component { render() { return ( <div> <UserConsumer> {username => { return <div>{username}</div> }} </UserConsumer> </div> ) } } context 的另一种用法 // userContext.js export default userContext // C.js import userContext from "./userContext" export class C extends Component { static contextType = userContext render() { return ( <div> {this.context} </div> ) } } 4. 表单 4.1 受控表单表单控件中的值由组件的 state 对象来管理，state对象中存储的值和表单控件中的值时同步状态的 class App extends Component { constructor () { this.state = { username: "" } this.nameChanged = this.nameChanged.bind(this) } nameChanged (e) { this.setState({username: e.target.value}) } render() { return ( <form> <p>{this.state.username}</p> <input type="text" value={this.state.username} onChange={this.nameChanged}/> </form> ) } } 4.2 非受控表单表单元素的值由 DOM 元素本身管理。 class App extends Component { constructor () { this.onSubmit = this.onSubmit.bind(this) } onSubmit(e) { console.log(this.username.value) e.preventDefault(); } render( <form onSubmit={this.onSubmit}> <input type="text" ref={username => this.username = username}/> </form> ) } 5. 路由 url地址与组件之间的对应关系，访问不同的url地址显示不同的组件。下载：npm install react-router-dom 5.1.1 路由基本使用 // App.js import React from 'react'; import { BrowserRouter as Router, Route, Link } from 'react-router-dom'; function Index() { return <div>首页</div>; } function News() { return <div>新闻</div>; } function App() { return ( <Router> <div> <Link to="/index">首页</Link> <Link to="/news">新闻</Link> </div> <div> <Route path="/index" component={Index}/> <Route path="/news" component={News}/> </div> </Router> ); } 5.1.2 路由嵌套 function News(props) { return ( <div> <div> <Link to={`${props.match.url}/company`}>公司新闻</Link> <Link to={`${props.match.url}/industry`}>行业新闻</Link> </div> <div> <Route path={`${props.match.path}/company`} component={CompanyNews} /> <Route path={`${props.match.path}/industry`} component={IndustryNews}/> </div> </div> ); } function CompanyNews() { return <div>公司新闻</div> } function IndustryNews() { return <div>行业新闻</div> } 5.1.3 路由传参 import url from 'url'; class News extends Component { constructor(props) { super(props); this.state = { list: [{ id: 1, title: '新闻1' }, { id: 2, title: '新闻2' }] } } render() { return ( <div> <div>新闻列表组件</div> <ul> this.state.list.map((item, index) => { return ( <li key={index}> <Link to={`/detail?id=${item.id}`}>{item.title}</Link> </li> ); }) </ul> </div> ); } } class Detail extends Component { constructor(props) { super(props); } const { query } = url.parse(this.props.location.search, true); console.log(query); // {id: 1} render() { return <div>新闻详情</div> } } 5.1.4 路由重定向 import { Redirect } from 'react-router-dom'; class Login extends Component { render() { if (this.state.isLogin) { return <Redirect to="/"/> } } }

382

life.caoalmost 3 years

一行配置构建速度提升，Webpack5持久化缓存

接近 10w 行代码项目开启后二次构建效果如上，第一次还无缓存需要41秒,第二次有缓存后构建只需2秒（不计算安装依赖时间，只计算同一机器上的构建时间）！ Webpack5 持久化缓存 Webpack5 的核心新功能之一就是带来了开箱即用的持久化缓存，前一段时间在组内部分前端项目,缓存了npm包与编译时缓存，让项目构建速度,效率倍增。改问题的时候让产品发出了下面的感慨，特写一篇文章安利一下 Webpack 持久化缓存这个新功能。开始使用下面这行 Webpack 配置就是构建速度倍增的秘密，一行配置，让你也成为让产品测试的那个仔。 //Webpack配置 cache：{ type： 'fileSystem' } 当然，在实际使用过程中，不建议使用这么简单粗暴的策略（原谅我的标题党），下面应该才是启用持久性缓存的经典配置： // Webpack 配置module.exports = { cache: { type: 'fileSystem', buildDependencies: { config: [__filename]//下文有详细解读 } }} 缓存失效策略（重点）既然这项功能对构建性能有优化，为何不默认开启呢？这是因为 Webpack 的开发者优先考虑到了安全性，持久化缓存虽然在 95% 的情况下能显著提升构建性能，但在 5%的情况下会破坏应用程序/工作流/构建，需要使用者对缓存策略有一定的了解才能正确使用（怕你翻车）。其实就是 Webpack 无法在默认开启的情况下确定何时缓存不再有效，并停止使用缓存，默认开启有一定的风险会导致构建出错。一个例子：当你修改项目的一个源码文件magic.js 时，Webpack 当然必须使 magic.js的缓存失效。构建需要再次处理文件，即运行 babel，typescript，whatever，解析文件并再次并再次运行代码生成。然后，Webpack可能也会使引用到该文件的源码文件的缓存失效，并且从包含的模块中重新构建此文件为此，Webpack 需要跟踪每个模块的fileDependencies contextDependencies和missingDependencies，并创建一个文件系统快照，用这个快照与实际文件系统进行比较，当检测到差异时，将为该模块触发重新构建，然后，对于构建中的缓存，Webpack会存储一个etag，只有当它匹配时，才会使用此etag，这些都是开箱即用，即 Webpack 可以闭环处理的部分。但是分析以下这些情况： npm 升级加载器或插件时更改配置时更改在配置中读取的文件时 npm 升级在配置中在配置中使用的依赖项时向构建脚本传递不同的命令行参数时有自定义构建脚本并更改它时 Webpack 无法开箱即用地处理所有这些可能导致缓存失效的情况，这样就可能会导致构建出问题。这就是为什么官方选择了使持久性缓存成为一个可选择的功能。而为了处理这些情况，官方还新增了许多相关的配置项。更多核心配置 cache.buildDependencies 用于允许指定构建过程的代码依赖项，Webpack 负责解析和跟踪指定值的依赖项。有两种可能的值类型：文件和目录。目录必须以斜杠结尾。其他所有内容都被解析为文件。对于目录，Webpack将分析最近的package.json以获取依赖项。对于文件，Webpack将查看 Node.js 模块缓存以找到依赖项。示例：构建通常依赖于Webpack本身的lib文件夹。可以这样指定： cache.buildDependencies: { defaultWebpack: ["Webpack/lib/"]} 但像 Webpack/lib或 Webpack 的依赖项（如watchpack，enhanced-resolved等）以及 node_modules 里的依赖包（简单策略，没有 hash，使用package.json中的version和name作为标识）其实已经是默认值，所以不必指定。但是构建通常也依赖于配置文件，所以官方推荐的配置如下： // Webpack 配置module.exports = { cache: { type: 'fileSystem', buildDependencies: { config: [__filename] } }} cache.version 当构建的某些依赖项不能表示为对文件的引用，例如从数据库读取的值，环境变量或在命令行上传递的值。对于这些值，就要用到这个配置了。示例：配置读取环境变量GIT_REV并使用DefinePlugin将此值嵌入到包中。这使GIT_REV成为构建的依赖项。可以这样指定： cache: { version: `${process.env.GIT_REV}`} cache.name 在某些情况下，依赖项会在多个不同的值之间切换，每次值更改都使持久性缓存失效将是浪费的。对于这些值，就可以用到cache.name了。示例：配置使用--env.target mobile|desktop参数为移动用户或桌面用户创建构建。可以这样指定： cache: { name: `${env.target}`} 更多配置更多配置与详解，请参考以下文档： https://webpack.js.org/configuration/cache/#cache https://github.com/webpack/changelog-v5/blob/master/guides/persistent-caching.md 核心插件不同于Vite的按需处理，Wepback 的处理流程，在打包项目时需要加载并编译所有代码，编译过程中文件解析、转译都会花费大量时间。在少量更改代码时冷启动也是需要进行全量编译，导致性能与Vite相差甚远。大致流程如下：构建模块依赖图：需要读取文件 -> loader 处理 -> 解析代码，从而得到模块描述Module对象。代码生成：需要逐个完成模块代码转译操作，得到代码生成结果CodeGenerationResult对象。资源整合生成产物：将模块编译结果整合成资源并输出资源描述对象Source。在开启缓存时，Wepback 通过内置的Cache实例（cache 的 type 为 memory，使用 MemoryCachePlugin。cache 的 type 为 filesystem，使用 MemoryWithGCCachePlugin）为上述三种对象实例提供缓存能力，从而减少不必要的编译开支，从而达到加速构建的目的。更多详细原理安利一篇好文章：超详细讲解 Webpack5 缓存实现原理，在此不详细展开。总结 Webpack5带来了开箱即用的持久化缓存，但因为有一定的风险，并没有默认开启，发现很多小伙伴升级之后并没有用上这项好用的新特性，所以写了这篇文章简单分享下使用心得～希望这篇文章能帮助你更好地理解和使用这个功能（当然，不考虑兼容性还是赶紧上 Vite吧）！

152

life.caoalmost 3 years

低代码之拖拽排序实现思路-徒手开

效果演示前沿低代码平台最常见的功能就是拖拽，不同的低代码产品拥有不同的拖拽实现。比如大屏低代码，组件可以自由拖拽，依托定位来实现组件的位置移动；中后台的低代码略有不同，它的布局依托元素本身特性，呈瀑布流形式，它不能自由拖拽，但能调整组件顺序。下面以中后台为例，讲解一下拖、放、排序、嵌套等功能在低代码中的实现。移动和拖放原理移动对于目标元素，在同一个画布中，从A点移动到B点，使用 mousemove 即可实现，它并非实际意义上的拖拽。位置计算：鼠标移动坐标 - （鼠标按下坐标 - 目标元素偏移）= 元素实际坐标拖放把目标元素从A容器放置到B容器的过程称之为拖放，包含一个拖和一个放两个动作。过程解析：给元素添加draggable=true即可实现元素拖拽效果，右侧盒子是不能直接接收一个元素对象的，当前需要使用dataTransfer在拖和放之间传递数据，右侧盒子获取到数据后，动态生成目标元素进行DOM渲染。关键代码： <div id="drag" draggable="true" ondragstart="drag(event)"></div><div class="box" ondrop="drop(event)" ondragover="event.preventDefault();"></div><script> // 拖拽时，保存ID function drag(ev) { ev.dataTransfer.setData('id', ev.target.id); } // 放置时，获取ID，并动态渲染 function drop(ev) { var data = ev.dataTransfer.getData('id'); ev.target.appendChild(document.getElementById(data)); }</script> 低代码拖放低代码开发为了更加便捷采用了react-dnd插件，核心的API依然是一个拖（useDrag）、一个放（useDrop）。左侧菜单为拖拽组件，中间画布为放置区域，拖放的过程实际上就是数据传递并动态渲染的过程。一、动态定义拖拽组件左侧菜单通常只需要把组件图标和组件名称遍历出来即可，通过数组循环遍历更加简单。 export default [ { type: 'form', title: '表单项', data: [ { icon: '', name: '文本框', type: 'Input', }, { icon: '', name: '按钮', type: 'Button', }, { icon: '', name: '多行文本框', type: 'TextArea', } }] 二、动态生成拖拽组件封装拖拽目标，外层容器直接遍历即可，此处只渲染了名称。 import { IDragTarget } from '@/packages/types/index';import { DragSourceMonitor, useDrag } from 'react-dnd';/** * 拖拽目标 * @param props 拖拽对象属性值 * @returns 返回可拖拽组件对象 */const DragMenuItem = (props: IDragTarget) => { const [{ isDragging }, drag] = useDrag( () => ({ type: 'MENU_ITEM', item: { type: props.type, }, collect: (monitor: DragSourceMonitor) => { return { isDragging: monitor.isDragging(), }; }, }), [], ); return ( <div className={styles.menuItem} style={{ color: isDragging ? '#f16622' : '#000', }} ref={drag} > {props.name} </div> );};export default DragMenuItem; type：用来设置接收的类型，画布中根据此type才能接收拖拽时传递的数据。 item：拖拽时携带数据。 collect：收集函数，根据monitor可获取当前拖拽目标的实时状态。三、画布接收组件使用自定义 Hook useDrop来绑定画布的接收区域。通过accept属性来设置接收的数据类型。 // 拖拽接收 const [collectedProps, drop] = useDrop({ accept: 'MENU_ITEM', drop(item: IDragTargetItem, monitor: any) { // 获取拖拽的组件类型 const type = item.type; // ... } }); return <div ref={drop} className="canvas"></div> 四、画布组件渲染左侧菜单拖拽组件时，设置了item参数，画布drop方法会接收该参数，我们只需要知道拖拽的组件类型即可，比如是：Input、Button还是Select，根据类型，动态获取该物料组件，从而进行动态渲染。 import * as Components from '@/packages/index';// 动态获取组件const Component: any = Components[item.type as keyof typeof Components];return <Component key={item.id} componentid={item.id} componenttype={item.type} config={item.config} events={item.events} api={item.api}/> 以上就是组件拖放过程，实际上只是数据传递过程，并非直接把组件拖拽上去，根据数据再去物料库中查找物料，从而渲染到画布中。组件拖放到画布中后，还需要保存到全局状态管理中，以备后面使用。拖拽排序画布中的组件要支持排序功能，画布中的组件最终保存在数组中，实际上就是数组的排序功能。想要实现组件顺序调整，需要设置画布中的每个组件既是拖拽组件，又是放置区域，此时大大增加了复杂度。画布中的组件通过动态渲染生成的，此处就需要动态绑定 drag 和 drop 对象，组件的渲染实际上发生在单独的渲染引擎组件中，画布本身只需要调用渲染引擎即可，假设渲染引擎为：MarsRender，代码参考： const [{ isDragging }, drag] = useDrag(() => { return { type: 'Component', item: { parentId: item.parentId, draggedId: item.id, }, collect: (monitor) => ({ isDragging: monitor.isDragging(), }), }; }); // 拖拽接收 const [collectedProps, drop] = useDrop({ accept: 'Component', hover({ parentId, draggedId }: any) { if (!ref.current) { return; } // 如果拖拽的组件和悬浮的组件是同一个则返回。 if (draggedId === item.id || parentId === item.id) return; moveCard(draggedId, item.id); }, }); // 动态获取组件 const Component: any = Components[item.type as keyof typeof Components]; return <Component ref={drag(drop(ref))} key={item.id} className={['mars-component', isDragging ? 'dragging' : '']} id={item.id} componentid={item.id} componenttype={item.type} config={item.config} events={item.events} api={item.api}/> 通过官方提供的drag(drop(ref))同时给元素添加既能拖拽，又能拖放的功能，这里从新定义一个新的type，专门处理画布中组件之间的拖放操作。当组件A悬浮到组件B上面时，递归查找，把A和B对象做互换即可。 // 组件排序moveElements(state, { payload }) { const { draggedId, overId } = payload; function deepFind(list: ComponentType[]) { return list.map((item, index) => { if (item.id == draggedId) { return state.elementsMap[overId]; } else if (item.id === overId) { return state.elementsMap[draggedId]; } else if (item.elements?.length) { item.elements = deepFind(item.elements); } return item; }); } state.elements = deepFind(state.elements);} 为了更加便捷获取元素对象，我们提前使用Map结构存储了一份组件数据，便于组件查找和赋值。数组当中依然需要保存一份完整的组件列表，用于渲染引擎遍历渲染画布。如果要做的更加细致，组件嵌套拖放组件嵌套实际上只需要开发一个父容器组件，保留一个插槽即可，同时给该容器组件绑定drop对象，能够接收拖拽目标。 const [collectedProps, drop] = useDrop<IDragTargetItem>({ accept: ['MENU_ITEM'], drop(item: IDragTargetItem, monitor: any) { const type = item.type; // .... }, }); return ( <div ref={ref}> <Form form={form} className={styles.searchForm} layout="inline" style={config.style} {...props}> <div className={styles.formWrap} ref={drop}> { elements?.length ? <MarsRender elements={elements || []} moveCard={moveCard} /> : <div className={styles.slots}>拖拽组件到这里</div>} </div> <div className={styles.formAction}> <Button type="primary" style={{ marginRight: 10 }} htmlType="submit"> 查询 </Button> <Button type="default" style={{ backgroundColor: '#fff' }} onClick={handleReset}> 重置 </Button> </div> </Form> </div> ); 容器组件绑定drop，当拖拽左侧菜单组件到该容器组件内时，同样接收该组件类型，动态获取该组件，在插槽的位置进行动态渲染。本次记录一下中后台低代码中，物料的拖拽、排序和嵌套功能，以及核心的开发思路。

125

life.caoalmost 3 years

如何更好的使用React中context

Context 提供了一个无需为每层组件手动添加 props，就能在组件树间进行数据传递的方法。基础使用context 通过react官方对context的定义，我们了解context为我们提供了一种，当需要在组件中多层传递我们props时，可以避免每一层都向下传递同样的props。像下面像上图中的组件结构，或许需要如下代码示例：(不使用context时) // App const [query, setQuery] = useState({ name: "", team: "", age: undefined, score: undefined }) const handleChange = (val) => { setQuery({...query, ...val}) } // FormContainer <FormContainer value={query} onChange={handleChange} /> // SearchForm <SeachForm value={value} onChange={onChange} /> // AgeSelect ScoreSelect <AgeSelect value={value.age} onChange={val => onChange({ age: val})} /> <TableContainer query={query} /> // DownloadButton <DownloadButton query={query} /> <PlayerTable query={query} /> 可以看的出，同样的东西传递了很多层，写法既繁琐也不利于后期维护。当使用了context时，我们则不必每一层传递props，而是通过context直接在对应的组件内直接获取和修改即可。示例：（使用context） const initState: QueryState = { name: "", team: "", age: undefined, score: undefined, }; function App() { const state = useState(initState); return ( <AppContext.Provider value={state}> <AppContainer /> </AppContext.Provider> ); } // 这样子我们可以通过useContext, 直接获取和修改我们需要的 // SearchForm const [query, setQuery] = useContext(AppContext); // AgetSelect const [query, setQuery] = useContext(AppContext); <Select value={query.age} onChange={val => { setQuery({ age: val }) }} /> context重复渲染问题上面context的使用减少了我们传递props的繁琐，但是会引入一个不必要的重复渲染问题。当我们通过context修改了App组件中的state时，整个组件树自上而下都会重新渲染，也就是说很多组件没有依赖到我们context中的state，但是在我们修改context的值时，却也引起了这些组件的render。我们可以通过react devtools高亮，来观察重新渲染的组件，如下图：可以看出我修改name的值时，相应的会修改context中state，但是那些没有依赖的组件（图1中未标红的组件）也发生了重新渲染，这个是一个性能牺牲，我们不答应。 context更好的使用要解决context重复渲染问题，也就是当修改context的值时，我们只要rerender那些依赖context的组件即可，不需要从顶层的整个组件树都渲染一遍。也就是说我们需要一个数据源，然后组件可以订阅数据源的变化，数据源变化时，我们通知订阅的组件变化，触发组件rerender即可。所以说我们可以简单实现一个发布订阅模型即可。 export type Listener<T> = (state: T) => void; export type Store<T> = { setState: (partial: Partial<T>) => void; getState: () => T; subscribe: (listener: Listener<T>) => () => void; }; export function createStore<T>(initState: T): Store<T> { let state = initState; const listeners = new Set<Listener<T>>(); const setState = (partial: Partial<T>) => { state = { ...state, ...partial }; listeners.forEach((listener) => { listener(state) }); }; const getState = () => state; const subscribe = (listener: Listener<T>) => { listeners.add(listener); return () => listeners.delete(listener); }; return { getState, setState, subscribe, }; } 上面就是一个简单的发布订阅的实现，然后接下来我们需要把它应用到react的应用中，思考：首先我们可以通过context将这个初始化store传递下去，在每个需要的组件中，我们可以通过（getState）获取我们需要的数据和通过（setState）来修改这个数据，然后通过（subscribe）来订阅这个store的数据源变化，然后当数据源变化时各个订阅组件来rerender即可。具体实现如下：初始化store，作为context传递 export type QueryState = { name?: string; team?: string; age?: string; score?: string; }; export const AppContext = createContext<Store<QueryState> | null>(null); const initState: QueryState = { name: "", team: "", age: undefined, score: undefined, }; const store = createStore(initState); function App() { return ( <AppContext.Provider value={store}> <AppContainer /> </AppContext.Provider> ); } 组件中添加订阅，由于组件订阅的逻辑基本一致，那我们可以定义一个hook来实现这部分逻辑 const useAppStore = (): [QueryState, (p: Partial<QueryState>) => void] => { const storeCtx = useContext(AppContext)!; const [state, setState] = useState(storeCtx.getState()); // add subscribe useEffect(() => { const unsubscribe = storeCtx.subscribe((s: QueryState) => { setState(s); }); return () => unsubscribe(); }, []); // 这里标红的代码，如果在react-18中 // 我们可以使用新的api useSyncExternalStore // useSyncExternalStore(store.subscribe, store.getState); // https://zh-hans.reactjs.org/docs/hooks-reference.html#usesyncexternalstore return [state, storeCtx.setState]; }; 组件获取或者修改 const DownloadButton = () => { const [query, setQuery] = useAppStore(); const { run, loading } = useRequest( () => { return downloadPlayers({ name: query.name, team: query.team, age: query.age, score: query.score, }); }, { refreshDeps: [query], manual: true, } ); return ( <Button type="primary" loading={loading} onClick={run}> 下载 </Button> ); }; function SearchForm() { const [query, setQuery] = useAppStore(); ......省略 } 最后我们查看经过优化后，我们的应用渲染的效果。可以通过高亮看到，差不多已经达到了我们预期的思考，只有依赖数据源的组件发生了渲染，其他的依旧如初，很好但是还可以更好~ One more thing... 在我们的demo中AgeSelect和ScoreSelect只需要query中个别字段，我们可以更进一步实现一下我们获取state的方法，从state中只获取我们需要的。可以加入一个selector function选取需要的数据。 const useAppStore = ( selector?: (state: QueryState) => any ): [Partial<QueryState>, (p: Partial<QueryState>) => void] => { const storeCtx = useContext(AppContext)!; const defaultSelectState = selector ? selector?.(storeCtx.getState()) : storeCtx.getState(); const [state, setState] = useState(defaultSelectState); // add subscribe useEffect(() => { const unsubscribe = storeCtx.subscribe((s: QueryState) => { const selectState = selector ? selector(s) : s; setState(selectState); }); return () => unsubscribe(); }, []); return [state, storeCtx.setState]; }; const ScoreSelect = () => { const [score] = useAppStore((state) => state.score); ...省略 }; 这样子做的好处是，如果添加一个只关注score的变化的组件，只有当score变化时，我们[只关注score]的组件才会重新渲染，其他的变化不会引起渲染，又做到了进一步优化。最后重新组织代码 // createStoreContext import { createContext, PropsWithChildren, useContext, useEffect, useRef, useState, } from "react"; import { createStore, Store } from "./createStore"; function createStoreContext<T>(initState: T) { const StoreContext = createContext<Store<T> | null>(null); const StoreProvider = ({ children }: PropsWithChildren) => { const storeRef = useRef<Store<T>>(); if (!storeRef.current) { storeRef.current = createStore(initState); } return ( <StoreContext.Provider value={storeRef.current}> {children} </StoreContext.Provider> ); }; const useStore = ( selector?: (state: T) => any ): [Partial<T>, (p: Partial<T>) => void] => { const storeCtx = useContext(StoreContext)!; const defaultSelectState = selector ? selector?.(storeCtx.getState()) : storeCtx.getState(); const [state, setState] = useState(defaultSelectState); // add subscribe useEffect(() => { const unsubscribe = storeCtx.subscribe((s: T) => { const selectState = selector ? selector(s) : s; setState(selectState); }); return () => unsubscribe(); }, []); return [state, storeCtx.setState]; }; return { StoreProvider, useStore, }; } // AppContext export type QueryState = { name?: string; team?: string; age?: string; score?: string; }; const initState: QueryState = { name: "", team: "", age: undefined, score: undefined, }; const { StoreProvider: AppContextProvider, useStore: useAppStore } = createStoreContext(initState); export { AppContextProvider, useAppStore }; // App import { AppContextProvider, useAppStore } from "./AppContext"; function App() { return ( <AppContextProvider> <AppContainer /> </AppContextProvider> ); } // other const ScoreSelect = () => { const [score, setQuery] = useAppStore((state) => state.score); ...省略 };

life.caoabout 3 years

装饰器模式的实践——Decorator

介绍定义装饰器（Decorator）模式的定义：指在不改变现有对象结构的情况下，动态地给该对象增加一些职责（即增加其额外功能）的模式。装饰模式3个角色： Client客户维护对修饰组件的引用 Component组件向其添加附加功能的对象 Decorator室内设计师通过维护对该组件的引用来“包装”该组件定义一个符合 Component 接口的接口实现附加功能(图表中的 addedMember) 装饰器模式的主要特点：在不改变原有对象的情况下，动态的给一个对象扩展功能，符合开闭原则。（扩展开放，修改封闭）通过使用不同装饰类及这些装饰类的排列组合，可以实现不同效果。装饰器模式会增加许多子类，过度使用会增加程序得复杂性。什么时候用在以下两种场景中我们可以考虑装饰器模式：希望在不影响现有对象功能的情况下更改对象减少处理一些API的重复代码，通过包装让模块更好的复用、更好的维护假如我们有一只猫，它有睡觉、吃饭等方法，我们也有电器，有充电功能。这两个类互不干扰。 class Animal{ constructor(){ // } sleep(){} cry(){} eat(){}}class Mechine(){ constructor(){ // } charge() {} work() {}}class Cat extends Animal{ constructor(){ // } sleep(){} }class Computer extends Mechine {}const cat = new Cat();const computer = new Computer(); 但是有一天我们有一只机器猫了，这只猫不仅可以叫还可以工作 class RobotCat extends Cat, Mechine { constructor(){}} JS继承通过原型链实现，原型链只有一个，只能继承一个类，以上代码不生效。即使是生效的，也会带来一些问题，机器猫不能睡觉，假如继承这两个类，会继承所有的方法，使得该类变得臃肿。设计原则中强调组合优于继承。如果可以通过包装组合的方式实现，将会更加灵活。关于@Decorator ES7中decorator借鉴Python中@decorator的语法糖，基于Object.defineProperty()方法实现。 Object.defineProperty()：它会直接在一个对象上定一个新属性，或者修改一个对象的现有属性，并返回此对象。具体的语法是： Object.defineProperty(obj, prop, descriptor)// obj：要定义属性的对象// prop：要定义或修改的属性的名称或Symol// descriptor：要定义或修改的属性描述符。// 可通过修改descriptor.value改变对象行为 ClassDecorator 类装饰器 declare type ClassDecorator = <TFunction extends Function>(target: TFunction) => TFunction | void;// 装饰器使用单个参数调用，该参数是要装饰的构造函数。通过类装饰器实现行为“继承”，只需要通过@moveDecorator 任意的类都有getPosition方法。 const moveDecorator: ClassDecorator = (target: Function) => { target.prototype.getPosition = (): { x: number; y: number } => { return { x: 100, y: 200 }; };};@moveDecoratorclass User {}const user = new Tank();console.log(user.getPosition());// { x: 100, y: 200 }// 这里@moveDecorator语法糖的作用与调用moveDecorator(User) 方法相当 MethodDecorator函数装饰器 declare type MethodDecorator = <T>(target: Object, propertyKey: string | symbol, descriptor: TypedPropertyDescriptor<T>) => TypedPropertyDescriptor<T> | void;// target:如果装饰器装饰的是静态成员，则target是类本身；如果装饰器修饰的是实例成员，则target是该类的protot// propertyKey:当前修饰的键值// descriptor:该key的属性描述符，可读可写，成员装饰器不能有返回值。实现某个方法的延时调用，通过@SleepDecorator(2000)，show方法在调用的时候会被延迟2秒执行。 const SleepDecorator = (times: number): MethodDecorator => { return ( target: Object, propertyKey: string | symbol, descriptor: TypedPropertyDescriptor<T>, ) => { // 将该方法原来的值通过method存储 const method = descriptor.value; // 重新赋值该方法 descriptor.value = () => { setTimeout(() => { method(); }, times); }; };};class User { @SleepDecorator(2000) public show() { console.log("delay 20000 method decorator"); }}const u = new User();u.show();// 20000ms 后输出 delay 20000 method decorator PropertyDecorator属性装饰器 declare type PropertyDecorator = (target: Object, propertyKey: string | symbol) => void; 我们通过属性装饰器来生成随机数，通过@RandomNumber，直接对类的实例生成number随机数。 const RandomNumber: PropertyDecorator = ( target: Object, propertyKey: string | symbol,) => { Object.defineProperty(target, propertyKey, { get() { return Math.random() * 10; }, });};class User { @RandomNumber public number: string | undefined;}const u = new User()console.log(u.number);// 控制台显示0-10的随机数 @Decorator语法糖，让“装饰器”应用代码实现更加的简洁和优雅，目前还属于未进入稳定阶段，我们可以用babel来转换为浏览器能识别的语言，未来ES7的这个语法可以让我们方便对类、属性的装饰。但是目前@Decorator还不能作用于函数，只能用于类和类的方法，也就是React开发中我们常用到的函数式组件无法使用该特性。应用常见防抖业务中常用到的防抖、节流的设计也是装饰器应用。 Debounce function debounce(timeout) { const instanceMap = new Map(); // Create a Map data structure with the instantiated object as the key return function (target, key, descriptor) { return Object.assign({}, descriptor, { value: function value() { clearTimeout(instanceMap.get(this)); instanceMap.set( this, setTimeout(() => { descriptor.value.apply(this, arguments); instanceMap.set(this, null); }, timeout), ); }, }); };}class Editor { content: any; constructor() {} @debounce(500) updateContent(content) { console.log(content); this.content = content; }}const e = new Editor();e.updateContent("11111");e.updateContent("22222");e.updateContent("33333");// 控制台最终输出 33333 高阶组件 React中的高阶组件也类似一个装饰器的作用。 React中HOC接收一个组件作为参数，并返回一个新的组件。我们基于装饰器原理，对传入函数进行功能的装饰，将一个组件转换成另一个组件。下面的例子我们通过类似插槽的方式将组件作为children传递给父级组件，父组件返回带有子组件的渲染。这种组合的形式也更加的灵活。 <Swiper defaultIndex={defaultIndex} direction="vertical" style={{ '--height': '100vh', }} onIndexChange={(index) => { setCurPage(index); }} > <Swiper.Item> <LottieContainer path={lottiePathMap.P2}> <Page1 /> </LottieContainer> </Swiper.Item> <Swiper.Item> <LottieContainer path={lottiePathMap.P3}> <Page2 /> </LottieContainer> </Swiper.Item> </Swiper> 业务开发中，企业PC端基于ant组件库进行二次封装，使其组件库风格与业务设计风格贴合。二次组件封装 import { Pagination } from 'antd';import IArrow from '@imgs/icons/arrow-right.svg';export default function ResetPagination(props: any) { const itemRender = (current: number, type: any, originalElement: any) => { if (type === 'prev') { return ( <span className='page-arrow-left'> <IArrow /> </span> ); } if (type === 'next') { return ( <span className='page-arrow-right'> <IArrow /> </span> ); } return originalElement; }; return ( <Pagination {...props} itemRender={itemRender}> {props?.children} </Pagination> );}// 我们将Pagination封装成ResetPagination，修改了上一页下一页的按钮。 HOC更趋向于复用可视化的逻辑，如果需要复用非可视化的逻辑，需要使用到React Hooks。其他“易混淆”的模式代理模式代理模式的特点在于隔离，隔离调用类和被调用类，通过一个代理去调用。为其他对象提供一种代理以控制对这个对象的访问。如在项目中用到的接口请求处理。最终我们通过暴露POST方法给外部，对axios进行了一层隔离。这在项目中是很常见的处理，可以更好的处理请求公共逻辑。以下是代码实现。 export const request = axios.create({ baseURL: apiHost, withCredentials: true,});...request的处理，此处省略...export const POST = (...args: PostParams) => { return request.post(...args).then((r) => r.data);}; ES6语法中，我们还可以用Proxy来创建对象的代理，实现对对象的拦截。适配器模式适配器是两个不兼容的接口之间的桥梁。适配器不是在详细设计时添加的，而是解决正在服役的项目的问题。如在项目中看到坐标转换的例子，后端返回坐标系A的数据，我们通过调用百度api将其转成百度坐标系。但是接口返回的坐标系并不是api中约定的格式，而百度坐标系转换后的坐标也不是我们需要的最终格式。我们在中间增加一个适配层进行入参和出参的格式处理。暂时无法在飞书文档外展示此内容入参需要将接口返回的对象数据类型进行转换成百度坐标转换器需要的字符串形式；出参将百度坐标转换器返回的Point数组类型转换成对象数据类型。以下是代码 // 调用百度api的方法function getGeoconvMultiterm(coords, from = 1, to = 5) { return new Promise((resolve, reject) => { const convertor = new BMap.Convertor(); convertor.translate(coords, from, to, data => { if (data && data.status === 0) { resolve(data.points || []); } else { reject(data); } }); });}// const batchTransform = async function ({ coords, revealFn, from, to, returnLatField, returnLonField,}) { const coordsArr = coords.split(';'); // 单次请求可批量解析10个坐标 const SINGLE_TRANSFORM_MAX = 10; // 请求次数 const requestFrequency = Math.ceil(coordsArr.length / SINGLE_TRANSFORM_MAX); // promise集合 const promises = []; // promise分批请求 for (let currentRF = 0; currentRF < requestFrequency; currentRF++) { const sliceArr = coordsArr.slice( currentRF * SINGLE_TRANSFORM_MAX, (currentRF + 1) * SINGLE_TRANSFORM_MAX, ); const pointsArr = sliceArr.map(e => { const point = e.split(','); return new BMap.Point(point[0], point[1]); }); promises.push(getGeoconvMultiterm(pointsArr, from, to)); } const promiseRes = await Promise.allSettled(promises); // promise结果处理 const result = promiseRes.map((p, index) => { if (p.status === 'fulfilled') { return p.value.map(e => ({ [returnLatField]: e.lat, [returnLonField]: e.lng, })); } else { // 兜底转换 const sliceArr = coordsArr.slice( index * SINGLE_TRANSFORM_MAX, (index + 1) * SINGLE_TRANSFORM_MAX, ); sliceArr.map(e => { const latlonArr = e.split(','); const bds = revealFn(latlonArr[0], latlonArr[1]); return { [returnLatField]: bds.lat, [returnLonField]: bds.lon, }; }); } }); // 二维数组解构 const arr2 = result.reduce((a, b) => a.concat(b)); return arr2;};export const batchWgsToBd = async function ( coords, returnLatField = 'lat', returnLonField = 'lon',) { return batchTransform({ coords, revealFn: wgs2bd, from: 1, to: 5, returnLatField, returnLonField, });};// 页面使用：由于接口定义可能不一致，为避免多次转换，我们在实际页面中调用转换器之前进行入参数据结构转换； const coords = this.pointUpList.map(e => e.pointLatlon).join(';'); const pointPath = await batchWgsToBd(coords, 'lat', 'lng'); 总结这三种模式都属于结构性设计模式，个人觉得他们主要区别是设计目的和意图的不同，实际在开发过程中并无明显的分界线。 1、装饰器模式从设计开始预测未来使用场景，识别出“装饰性”的功能，再进行代码设计，代理模式中要设计中间层逻辑控制访问对象的安全性。两者有异曲同工之处。 2、装饰器模式在不影响原有的功能基础上增加的功能，这一点跟适配器的情况也有些殊途同归。在开发过程中，不需要指定一定要使用某种设计模式来实现功能，他们都有些相似。不管怎样，他们都是实现的工具，让我们更好的保持开发者思路去设计和编程。

life.caoabout 3 years

WebP方案的探索与实践

背景当我们在做网站性能优化的时候，减少图片大小，拆分大体积的包都是可采用的方法，那么对于减小图片的大小，我们可以通过进行压缩图片处理，可是压缩比例一直是前端开发和设计师争执的焦点。压缩比例大的话，可以有效减少图片体积，对页面加载有利，但是却损失了像素，是设计师无法容忍的。在这种矛盾的场景下，我们既要最大程度的压缩图片又要保持足够的清晰，WebP 便应运而生 Webp是什么？引自Google 解释 WebP is a modern image format that provides superior lossless and lossy compression for images on the web. Using WebP, webmasters and web developers can create smaller, richer images that make the web faster. 我们可以看到几个比较关键的字样lossless and lossy, smaller 、richer、faster，原文翻译为它是一种提供有损压缩和无损压缩的图片格式，可以创建更小、更丰富的图片，使网页加载更快。相比较Jpg\png\jpeg有什么优势？优势体现在同质量的前提下，WebP体积大约只有JPEG的1/3，对于采用大量图片的网页，WebP格式可以节省大量带宽，大幅提升网页加载速度；同时具备了无损和有损的压缩模式、Alpha 透明以及动画的特性，下面是对比 PNG 原图、PNG 无损压缩、PNG 转 WebP（无损）、PNG 转 WebP（有损）的压缩效果：从上图我们可以得出结论 webp的体积相较于原图有较大的减小 png转为webp之后的压缩率高于 PNG 原图压缩率那么对于webp各大浏览器的兼容性是怎样的呢？我们从caniuse.com查看webp在浏览器的支持率,可以看出chrome/android浏览器已经全量支持了，在高版本的safari中也已经支持了，但是在一些低版本的Ie 和safari中不支持即使是在全球范围内已经有了96.8% 的兼容率，在国内大概也有80.88% 的兼容率，但是我们在使用时也是要考虑在低版本浏览器的兼容性，下文中也有对兼容性的处理。使用webp的收益可以降低获取图片的时间我们来看一个图片对比图我们可以看到一张同样的一张图片格式不同，webp 格式的只有png的1%, 图片体积锐减，那么随之我们页面加载的速度也会更快。大家可以自己体验下。带宽成本我们以市场上各大互联网公司为例， YouTube 的视频略缩图采用 WebP 格式后，网页加载速度提升了 10%；谷歌的 Chrome 网上应用商店采用 WebP 格式图片后，每天可以节省几 TB 的带宽，页面平均加载时间大约减少 1/3； Google+ 移动应用采用 WebP 图片格式后，每天节省了 50TB 数据存储空间。在上文中，我们已经看到了使用webp带来的收益，那么在我们的项目中应该怎么去使用webp 以及在引用时都有哪些要求呢？大家可以接着往下看，大致可以罗列为以下三点：引入webp要求既可以支持远端资源的引入，又可以支持本地资源的引入在项目中可以支持设置webp的覆盖率，根据项目使用webp时的反馈情况，逐渐放开webp的使用量只加载使用的类型的资源方案要点在本地资源中，如何根据jpg|jpeg|png 生成 webp 在生成webp之后，如何根据浏览器的支持以及放量的覆盖，在业务Diy组件中引入对应的图片资源如何引入公用的css module ，不需要在每个组件的css module中引入解决引入要求及阐述要点如何根据jpg|jpeg|png 生成 webp 我们可以看webp的官文介绍 WebP includes the lightweight encoding and decoding library [libwebp](https://developers.google.com/speed/webp/docs/api) and the command line tools [cwebp](https://developers.google.com/speed/webp/docs/cwebp) and [dwebp](https://developers.google.com/speed/webp/docs/dwebp) for converting images to and from the WebP format, as well as tools for viewing, muxing and animating WebP images. The full source code is available on the download page. 有三种方案进行生成webp a.使用[libwebp](https://github.com/webmproject/libwebp/blob/main/webp_js/index_wasm.html)将其他格式的图片转为webp格式优点：能在浏览器享受WebP格式的优势。缺点：实时转换格式，消耗浏览器性能；有一定的延迟；在css中的引用无法处理 b.使用命令行进行生成 # 可以使用 brew install cwep进行安装 # 运行 cwebp -h 命令检查 cwebp 是否安装ok # cwebp [options] input_file -o output_file.webp # options 我们只需关心 -q即可其他参数大家可以查阅cwep的具体参数 # -q 质量指数（压缩率），有损压缩有效，无损压缩忽略 # -o 输出图片名称格式 cwebp -q 75 input_file -o output_file.webp 优点：可以写脚本进行动态生成webp，不依赖于任何三方 c.借助一些网站进行生成webp 例如 anywebp 优点：快速生成，只需进行拖拽即可缺点：需要预处理，耗费人力 H5端分为两部分，一是在css样式中支持webp，另外一种是image src 的引入 image src 的引入重写Image组件在baseImage组件中根据 import React, { useMemo } from 'react' import webpInstance from 'app/webp' interface IBaseImage { src: string isLocal?: boolean // 是否是引入本地图片 className?: string [key: string]: any } const BaseImage = ({ src, isLocal = false, className, ...props }: IBaseImage) => { const isLunaSrc = useMemo(() => { return src.indexOf('luna') !== -1 }, [src]) const imgSrc = useMemo(() => { if (webpInstance.support) { if (isLocal) { return src } else { return isLunaSrc ? `${src}?x-oss-process=image/formate,webp` : src } } else { return src } }, [isLocal, isLunaSrc, src]) as unknown as string return <img className={className} {...props} src={imgSrc} alt="" /> } export default React.memo(BaseImage) WebP方案的ROI 在我们调研一种技术方案的时候，都要评估该技术引入的收益，也是我们所说的**ROI** 如果你决定使用WebP的话，以下数据可能会对你有所帮助图片大小减小到原来的1/6 DCL由原来的3.79s降低到2.76s，下降了27%，FCP由原来的4.53s降低到3.32s，下降了26.7% 左右使用正常png 使用Webp之后总结我们从Webp的使用背景以及收益出发，介绍了什么是webp、兼容性、生成方式等，以及在业务项目中是如何灰度的使用，导出全量图片资源的引用路径，还有后面在业务项目中是如何实践，所产生的收益。

React 中表单的规范和核心

契机最近一年都在做B端的项目，由于存在着大量的表单场景，做了一段时间后发现在表单功能上的实现方式都会因人而异，并没有一个统一的规范。因此，想在这里聊聊关于我对于 React 表单的一些见解。核心法则 - 单一数据源(Single Source Of Truth) 首先要明确一点，表单中的字段都需要存储在单一的数据源store中。 store中的状态与组件的视图是一一对应的，这样保证了数据的流动是单向的，代码在更易读的同时也更便于之后的维护，如下图所示：而当我们没有单一数据源的话，只是将状态交由给我们的表单组件维护，就很容易出现父与子、兄与弟、孙与爷之间的数据传输。在如此混乱的层级结构，其中的逻辑会变得难以理清，从而造成代码腐败。如下图所示：受控组件(Controlled Component) 即自身内不存在状态(例 useState, useContext, useReducer 等等...)的组件受控组件是实现单一数据源的基石。只有将组件的状态交由外部数据源（即store）管理，我们才能实现上述的单一数据源原则。表单组件只需要关注状态的输入（value）和变化（onChange），这样可以通过其他组件来更新表单状态，也可以轻松地在其他UI组件之间共享状态。 // good 受控组件 function Input({ value, onChange }) { return ( <input value={value} onChange={function handleChange(ev) { onChange(ev.target.value); }} /> ); } // bad 非受控组件 function Input() { const [value, setValue] = useState() return ( <input value={state} onChange={function handleChange(ev) { setValue(ev.target.value) }} /> ); } 衍生状态(Derived State) 在很多时候对于衍生状态，常常会新增一个状态来维护(例如useState)，但实现方式往往是错误的。如下： function Fullname({ firstName, setFirstName, lastName }) { const [fullname, setFullname] = useState(firstName + lastName) return ( <div> <p>{fullname}</p> <input value={firstName} onChange={function handleChange(ev) { setFirstName(ev.target.value); setFullname(ev.target.value + lastName) }} /> </div> ); } 这样做违反了我们之前提到的核心法则 - [单一数据源] 在上面的例子中，我们使用useState来管理fullName状态，但是fullName并不是由firstName和lastName这两个状态派生出来的。如果外部传入的props中的firstName或lastName发生变化，你会发现fullName并不会更新。为了实现单一数据源，我们应该将fullName作为firstName和lastName的衍生状态，而不是独立维护的状态。我们可以按照以下方式进行修改： function Fullname({ firstName, setFirstName, lastName }) { // fullname 是由 firstName 和 lastName 计算得出的 const fullname = firstName + lastName return ( <div> <p>{fullname}</p> <input value={firstName} onChange={function handleChange(ev) { setFirstName(ev.target.value); setFullname(ev.target.value + lastName) }} /> </div> ); } 性能优化(Performance Optimization) 在上面的设计中，store 中任何微小的变化都会引起整个表单的重渲染。在一些简单的场景下，上面的写法足够好用。但在复杂表单场景下，你就需要对受控组件进行颗粒化更新，而不是全量更新。最简单的实现方式是使用 React.memo 来减少组件的不必要更新，示例如下： const MemoInput = React.memo(Input) 但是，当需要将 store 中的状态传递到层级较深的组件，并沿着组件树传递时，沿途的组件都会重新渲染，这也会造成性能问题。为了减少这些不必要的渲染，我们可以采用发布订阅的设计模式。以下是一个发布订阅模式的伪代码示例： function Input({ name }) { const store = useStore() const [value, setValue] = useState(store.get(name)) useEffect(() => { const unsubscribe = store.subscribe(name, newValue => { setValue(newValue) }) return unsubscribe }, [store, name]) return ( <input value={value} onChange={function handleChange(ev) { store.set(name, ev.target.value) }} /> ) } 在上述示例中，Input 组件通过订阅 store 中的 name 实现了只关心当前 name 变化的值。目前主流的表单库的核心原理也大致如此，例如 Antd 表单中的 namePath 和 Formik 中的 fieldName。通过采用发布订阅模式，我们可以将表单项的更新范围限制在需要更新的组件上，避免了不必要的渲染。这样可以大大提高表单的性能，尤其在复杂表单场景下，更加有效地优化表单的渲染和响应性能。竞态问题(Race Conditions) 在业务中，我们经常遇到这样的情况：我们需要通过异步请求获取当前用户的信息，并将其作为表单的默认值。通常的做法是先渲染表单，然后在数据加载完成后重新填充表单。这种情况下可能会出现竞态问题。当用户正在填写表单时，如果在数据加载完成前重新填充表单字段，之前用户填写的内容就会丢失，用户体验将变得糟糕。为了避免这种情况，我们需要确保在异步请求完成之前不允许修改表单，例如： function UserForm() { const { user, isLoading } = useUser() if(isLoading) return "loading" return ( <Form initialValues={user}> {...} </Form> ); } 最后 /* * _oo0oo_ * o8888888o * 88" . "88 * (| -_- |) * 0\ = /0 * ___/`---'\___ * .' \\| |// '. * / \\||| : |||// \ * / _||||| -:- |||||- \ * | | \\\ - /// | | * | \_| ''\---/'' |_/ | * \ .-\__ '-' ___/-. / * ___'. .' /--.--\ `. .'___ * ."" '< `.___\_<|>_/___.' >' "". * | | : `- \`.;`\ _ /`;.`/ - ` : | | * \ \ `_. \_ __\ /__ _/ .-` / / * =====`-.____`.___ \_____/___.-`___.-'===== * `=---=' * * * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * * 佛祖保佑永不宕机永无BUG */

life.caoover 3 years

自定义 hook 实现 React 状态管理

一、背景最近在写组件库 demo 文档的时候，希望能实现动态主题切换实时预览功能。预期效果如下：右上角 ThemeSwitch 组件在更改内部主题色状态 color 时，希望实时更新左上角标题内容及主题色、iframe 组件内部组件主题色。二、能简单实现吗？上面的场景其实就是解决多个组件内部状态同步的问题，我相信大家第一反应肯定是上 Redux、Store 这种状态管理库，相关文档及如何使用大家都很熟悉，但是这里有两个问题值得我们思考：我只是想同步个状态，能简单实现不引入第三方类库么？状态管理类库内部是如何实现的，原理是什么？三、问题分析有问题，先分析问题。分析问题的思路有很多，大致可以分为两种： 0 - 1 ：先干，把代码跑起来，一步步遇到问题，解决问题；合适解题路径较清晰问题； 1 - 0 ：从结果出发，分析要想达到该结果的前置条件，追本溯源；适合拆解复杂问题；这里我们采用 1 - 0 的方法来分析：通知同步要想达到状态同步，当主题切换组件 ThemeSwitch 改变内部主题状态，执行 setColor(newColor)时，我们只要通知其他组件执行同样 setColor(newColor) 操作更新自己的状态就行，这样就达到了状态同步目的：如何通知？通知其实就是执行各个组件内部的 setColor 方法，这里就需要将 setColor 收集起来，然后在需要同步的时候依次调用，结合上步的通知，我们很容易想到这是一个发布-订阅模型。各组件在声明内部状态 useState() 时，是个很好的订阅时机，我们可以自定义一个 hooks useColorState 劫持该操作，作为 Controller，维护订阅-发布功能：四、解决通过分析，我们得到了解决状态同步的基本思路：我们需要一个自定义的 hook 去拦截各子组件内部状态的定义，以便绑定订阅关系，留下操作空间；自定义 hook 需要实现发布订阅功能，在状态变更时通知各组件；自定义 hooks // useColorState.js export default function useColorState() { const [color, setColor] = useState(); return [color, setColor]; } 一个简单的发布-订阅模型 class ColorChanger { constructor() { this.color = 'orange'; this.callBacks = []; } // 订阅 listen(cb) { this.callBacks.push(cb)； } // 发布 publish() { this.callBacks.forEach(cb => cb(this.color)); } } 订阅完成订阅和内部状态初始化： let colorChanger; export default function useColorState() { const [color, setColor] = useState(); useEffect(() => { colorChanger = colorChanger || new ColorChanger(); colorChanger.listen(setColor); setColor(colorChanger.color); }, []) return [color, setColor]; } 发布这里 hook 返回只是更新自己状态的 setColor，我们需要通知其他组件: function useColorState() { const [color, setColor] = useState(); const changeColor = val => { colorChanger.setColor(val) } // ... return [color, changeColor]; } class ColorChanger { // ... setColor(color) { this.color = color; this.publish(); } } 取消订阅当组件卸载时，我们需要取消订阅，将该组件的 setColor 从 colorChanger.callbacks 中删除即可： class ColorChanger { // ... unlisten(cb) { this.callBacks.splice(this.callBacks.indexOf(cb), 1); } // ... } function useColorState() { useEffect(() => { // ... return () => { colorChanger.unlisten(setColor) }; }, []) } 五、还要到这里，通过自定义 hook 和发布-订阅模式，我们实现了一个简单的状态同步功能，但是依然有一些问题在 debug 时被发现了：小优化在 setColor(sameColor) 时，依然触发了发布，而发布是一个高成本操作，所以这里需要优化： class ColorChanger { // ... setColor(color) { if （this.color === color） return; this.color = color; this.publish(); } } Reducer 优化让人上瘾，我们这里只是维护了一个 string 类型的简单状态 color，Redux store 一般都是拥有复杂深度的 Object，那 Redux 要怎么对比新老状态是否变更了呢？答案是 Reducer，以下是一个 Reducer 的定义： const newState = reducer(oldState, action); 所以我们也改造下 useColorState: function colorReducer(state = {color: 'orange'}, action) { return action.color === state.color ? state : {color: action.color}; } export default function useColorState(colorReducer) { // ... colorChanger = colorChanger || new ColorChanger(colorReducer); // ... } class ColorChanger { // ... setColor(action) { const newState = this.colorReducer(this.state, action); if(this.state === newState)) return; this.state = newState; this.publish(); } } Redux Reducer 设计避免了每次需要深度遍历比较新旧状态，而是通过 reducer 判断没更新就返回老对象，这样我们就能直接 === 比较对象地址，约定有时比直接解决问题有效。六、结尾到这里基本结束了，当然肯定还有很多需要优化的点：比如 changeColor 应该使用 useCallback 包裹防止 setColor 作为 props 传递产生的不必要的渲染、比如发布的时候应该做个队列确保本轮通知完成再进行下轮状态变更... 本文只是通过实际问题提供一个思考过程：很多第三方类库看起来代码量很多，技术原理可能并没有想象中那么复杂，多数代码是为了应对各种边界情况、性能优化、支持同步异步等做了扩展，有的库甚至为了追求大而全堆了一些和核心能力不相关的代码，造成我们阅读源码起来不是很顺畅。所以只有分析了问题的核心，了解了基础的技术思路，我们使用起来才会更得心应手。

life.caoover 3 years

Hooks中使用MVC思想

引言怎么延缓代码结构熵增的过程？为什么基于视图开发会给后续迭代埋坑？ Hooks 我们常听说，那可以怎么去写？遇到的问题前端发展到了今天，伴随着日益复杂的交互，越来越多的逻辑放到前端进行实现。在迅速膨胀的业务场景中，我们会发现，代码在迭代的过程中越发地难以维护。在一些迭代频率比较高的场景，短短几个版本的时间内，代码就会变得难以阅读和理解。想知道某个页面元素在什么情况下显示，从判断条件 a 看到变量 b，再跳到文件 c，好一番折腾才能知道这里面的逻辑。那这一系列问题的原因出在哪呢？一、业务场景本身就具有较高的复杂度。对需求涉及的场景全局掌握，需要的不仅是知识的广度，还有对业务了解的深度。不能全局的掌握所有场景，在设计初期有纰漏是在所难免的事情。二、技术模型满足不了业务的膨胀。前端开发的过程中，我们常常是「视图驱动」的，拿到一个需求后，根据业务需求提炼出一个技术模型，然后围绕它进行编码开发。但是用户的需求不可能被一个既定的技术模型所概括，业务的改动和膨胀都极易对这个已有的模型造成致命的破坏。三、知识的丢失。同一场景不同同事介入开发、负责模块的同事离职、跨项目支持、注释的不完善等等，代码虽然在仓库中保存下来了，但是知识——代码背后的逻辑、设计的出发点和考量多多少少都会出现丢失。之前是怎么做的前面的废话有点多，我们接下来直入正题。首先，假定我们有一个需求，实现这么一个表单：具体交互提交揽收、干线、派送三段的费用，然后选中优惠券之后可以给指定某一段的费用打折（业务逻辑）提交的时候，如果有优惠券，但是用户没有选，弹窗提醒用户（交互逻辑）我们拿到需求之后，一般都是基于 UI 稿，从页面出发，先考虑怎么实现界面，然后再根据产品的 PRD，把交互逻辑做成一些判断条件，去决定某些部分是否展示。但是这样「视图驱动开发」做法是有问题的，具体什么问题我们看完代码后分析。 <script> export default { data() { return { form: { pickupFee: undefined, zxFee: undefined, deliveryFee: undefined, couponId: undefined, }, isUseCoupon: false, activatedCoupon: null, couponList: [] } }, computed: { total() { const { activatedCoupon, form, isUseCoupon } = this const { pickupFee, zxFee, deliveryFee } = form if (!isUseCoupon || !form.couponId) { return pickupFee + zxFee + deliveryFee } else { const map = { pickup: pickupFee, zx: zxFee, delivery: deliveryFee } return Object.keys(map).reduce((result, feeType) => { const originalFee = +map[feeType] || 0 const subFee = feeType === activatedCoupon.type ? originalFee * activatedCoupon.discount : originalFee return result + subFee }, 0) } }, }, mounted() { // 模拟请求优惠券列表 this.couponList = [ { id: 1, name: '揽收费专享', type: 'pickup', discount: 0.8 }, { id: 2, name: '干线费专享', type: 'zx', discount: 0.64 }, { id: 3, name: '派送费专享', type: 'delivery', discount: 0.12 } ] }, methods: { setActivatedCoupon(selectedId) { this.activatedCoupon = this.couponList.find(item => item.id === selectedId) }, onSubmit() { // 一些校验逻辑 const { couponList, isUseCoupon, form } = this if (!!couponList.length && (!isUseCoupon || !form.id)) { alert('您有优惠券，确定不使用么') } console.log('submit!'); } }, } </script> <template> <el-form ref="form" :model="form" label-width="110px"> <el-form-item label="揽收费"> <el-input v-model="form.pickupFee"></el-input> </el-form-item> <el-form-item label="干线费"> <el-input v-model="form.zxFee"></el-input> </el-form-item> <el-form-item label="派送费"> <el-input v-model="form.deliveryFee"></el-input> </el-form-item> <el-form-item label="是否使用优惠券"> <el-switch v-model="isUseCoupon"></el-switch> </el-form-item> <template v-if="isUseCoupon"> <el-form-item label="优惠券列表" > <el-select v-model="form.couponId" placeholder="请选择优惠券" @change="setActivatedCoupon"> <el-option v-for="item in couponList" :key="item.id" :label="item.name" :value="item.id" ></el-option> </el-select> </el-form-item> <el-form-item label="折扣" > <span>{{ form.id ? activatedCoupon.discount : '未选中优惠券' }}</span> </el-form-item> </template> <el-form-item label="总价"> <span>¥：{{ total }}元</span> </el-form-item> <el-form-item> <el-button type="primary" @click="onSubmit">提交</el-button> <el-button>取消</el-button> </el-form-item> </el-form> </template> 现在我们来回头看，「视图驱动开发」有什么问题？我们把目光投向 computed：在实现中，activatedCoupon依赖于isUseCoupon和form.id去计算。它们彼此之间有无形的线牵扯着，计价的逻辑就变得不纯粹了。假如有另外一个计价模式完全一样的场景，不过页面和交互上没有「是否使用优惠券」这个限制。我们尽管有完全一样的计价逻辑，也没办法复制这段代码过去直接使用，因为它和某个需求中特有的交互逻辑耦合在了一起。这只不过是一个复杂度很小 demo，纠缠在一起的代码不过数行。但事实上，随着业务增长，一个中等规模的组件，字段的数量轻松地就能达到 20 个以上，字段与字段之间，computed，watch，mixin，彼此依赖，互相纠缠，有形的、无形的线错综复杂地交错在一起。到那时，要想知道某个文字 / 列表 / 图表等组件在什么条件下才显示，就只能从这一团乱麻中一根一根地捋了。是从哪一步开始，原本有条不紊的线乱作了一团？归根结底，是因为业务逻辑和视图逻辑耦合在一起。是否使用优惠券、是否选中优惠券、有优惠券却不使用在提交时候需要提示。这些都是交互逻辑，但是却和计价的业务逻辑耦合在了一起。随着业务场景的膨胀，它们会耦合得更加密切，导致在一定量级之后，我们开发变得如履薄冰：原本的代码量级很大，复杂度很高。根本不敢去动原来的历史代码，只能在这此基础上添加自己的逻辑。这样就很可能导致逻辑冗余，或者隐性的逻辑冲突。原本的代码耦合度太高，没办法复用，但是重新去开发需要大量的时间。只能 cv 一份，在备份上修修改改，满足新需求。一些本不属于新需求的逻辑，如果没删干净，就会给后续迭代和代码阅读埋下巨大的隐患。如果删改得不恰当，导致在一些边际情况中代码无法正常运行，更是如堕深坑。可以怎样优化我们可以应用 MVC 的理念对逻辑进行解耦，来优化我们的代码。首先定义一个model，描述该业务逻辑中用到的所有字段： // order-model.js export default class Order { pickupFee = undefined zxFee = undefined deliveryFee = undefined couponId = undefined total = 0 } 然后提供操作model的service，里面封装的就是我们前文说到的「业务逻辑」： // order-service.js function countFeeByCoupon (feeObj, coupon) { const fee = +feeObj.fee || 0 if (!coupon) return fee const discount = coupon && coupon.type === feeObj.type ? coupon.discount : 1 return fee * discount } export default class OrderService { static countTotal(order, coupon) { const { pickupFee, zxFee, deliveryFee } = order const arr = [ { fee: pickupFee, type: 'pickup', }, { fee: zxFee, type: 'zx', }, { fee: deliveryFee, type: 'delivery', } ] order.total = arr.reduce((acc, cur) => { return acc += countFeeByCoupon(cur, coupon) }, 0) } } 接着是contorller，将原本「业务逻辑」和「视图逻辑」耦合的部分抽离至此，提供给视图层： // order-controller.js import Order from './order-model' import OrderService from './order-service' export default class OrderController { model = new Order() isUseCoupon = false couponList = [] activatedCoupon = undefined initCouponList() { this.couponList = [ { id: 1, name: '揽收费专享', type: 'pickup', discount: 0.8 }, { id: 2, name: '干线费专享', type: 'zx', discount: 0.64 }, { id: 3, name: '派送费专享', type: 'delivery', discount: 0.12 } ] } countTotal() { OrderService.countTotal(this.model, this.activatedCoupon) } setActivatedCoupon() { const { couponList, isUseCoupon } = this if (isUseCoupon) { this.activatedCoupon = couponList.find(item => item.id === this.model.couponId) } else { this.activatedCoupon = null } this.countTotal() } submit() { // 一些校验逻辑 if (this.couponList.length && !this.activatedCoupon) { alert('您有优惠券，确定不使用么') } console.log('submit!'); } } 最后就是利用controller去渲染最后的视图层了： <script> import OrderController from './order-controller'; export default { data() { return { controller: undefined, } }, created() { this.controller = new OrderController() this.controller.initCouponList() }, watch: { 'controller.model': { deep: true, handler() { this.controller.countTotal() } }, 'controller.isUseCoupon'() { this.controller.setActivatedCoupon() } }, methods: { setActivatedCoupon() { this.controller.setActivatedCoupon() }, doSubmit() { this.controller.submit() } } } </script> <template> <el-form ref="form" :model="controller.model" label-width="160px"> <el-form-item label="揽收费"> <el-input v-model="controller.model.pickupFee"></el-input> </el-form-item> <el-form-item label="干线费"> <el-input v-model="controller.model.zxFee"></el-input> </el-form-item> <el-form-item label="派送费"> <el-input v-model="controller.model.deliveryFee"></el-input> </el-form-item> <el-form-item label="是否使用优惠券"> <el-switch v-model="controller.isUseCoupon"></el-switch> </el-form-item> <template v-if="controller.isUseCoupon"> <el-form-item label="优惠券列表" > <el-select v-model="controller.model.couponId" placeholder="请选择优惠券" @change="setActivatedCoupon"> <el-option v-for="item in controller.couponList" :key="item.id" :label="item.name" :value="item.id" ></el-option> </el-select> </el-form-item> <el-form-item label="折扣" > <span>{{ controller.activatedCoupon ? controller.activatedCoupon.discount : '未选中优惠券' }}</span> </el-form-item> </template> <el-form-item label="总价"> <span>¥：{{ controller.model.total }}元</span> </el-form-item> <el-form-item> <el-button type="primary" @click="doSubmit">提交</el-button> <el-button>取消</el-button> </el-form-item> </el-form> </template> 改造完之后，视图层中没有业务逻辑的丝毫痕迹，阅读起来很清爽，更便于快速地掌握需求的场景。虽然总体逻辑被抽成了view->controller->service->model的多层结构，结构变得更复杂，代码量更多了，但是换来了是更高可阅读性和可维护性。此外，业务逻辑被纯粹地保存在service中，便于复用和迭代。后续开发新的业务逻辑，在制定的service中继续添加新功能即可；如果有类似的需求，也可以很大限度的复用这些代码，由于它是无状态的，所以它可以无缝地接入到任意的项目，任意一种框架。思考相信大家看完优化代码之后，心里会有一些疑惑：视图层和controller有必要分开写么，直接把controller的逻辑放在视图层里面不也可以么？如何拆解，怎么划分业务逻辑和视图逻辑，之间的边界如何定义？每个需求都适合这种拆解么，都划分成 MVC 三层，看起来也太麻烦了，有必要这样封装么？的确，上面视图层和controller分开写，只不过是为了很清晰地展示 MVC 理念在逻辑解耦中的应用。实际开发中我们完全没必要分开写，徒增额外的逻辑。至于业务逻辑和视图逻辑的划分，不同的视角，会有不同的划分结果，这里面肯定没有一个确切的标准。我们可以尝试从用户角度出发，把用户交互引起的页面变动定义为视图逻辑，页面变动所依赖的数据实体变更定义为业务逻辑。这只是万千方法中的一种，仅供参考。需要注意的是，这个标准在团队内部需要保持一致，不然大家从不同角度进行逻辑解耦，得到的service不能在不同的场景中复用，那所有的努力也就没有意义了。最后就是意义。我们回头看问题的症结：业务逻辑和视图逻辑耦合。拆分成 MVC 三层只不过是其中的一个办法。像是 Vue3 composition API 和 React 的 Hooks 其实都在鼓励我们把纯粹的、无状态的业务逻辑从视图逻辑中抽离出来。MVC 的model和service部分如果合并在一起，和封装 Hooks 的最终形态非常类似。而在具体的组件中引入useXXX的 Hooks 进行渲染，和在视图层中通过controller调用数据实体的service不也一样么。 // use-coupon.js function countFeeByCoupon (feeObj, coupon) { const fee = +feeObj.fee || 0 if (!coupon) return fee const discount = coupon && coupon.type === feeObj.type ? coupon.discount : 1 return fee * discount } export default function (order, coupon) { const { pickupFee, zxFee, deliveryFee } = order const arr = [ { fee: pickupFee, type: 'pickup', }, { fee: zxFee, type: 'zx', }, { fee: deliveryFee, type: 'delivery', } ] return arr.reduce((acc, cur) => { return acc += countFeeByCoupon(cur, coupon) }, 0) } <script setup> import { reactive, watch } from 'vue'; import useCoupon from './use-coupon' const state = reactive({ isUseCoupon: false, activatedCoupon: undefined, }) const form = reactive({ pickupFee: undefined, zxFee: undefined, deliveryFee: undefined, couponId: undefined, total: 0 }) const couponList = reactive([ { id: 1, name: '揽收费专享', type: 'pickup', discount: 0.8 }, { id: 2, name: '干线费专享', type: 'zx', discount: 0.64 }, { id: 3, name: '派送费专享', type: 'delivery', discount: 0.12 } ]) function countTotal() { form.total = useCoupon(form, state.activatedCoupon) } function setActivatedCoupon() { if (state.isUseCoupon) { state.activatedCoupon = couponList.find(item => item.id === form.couponId) } else { state.activatedCoupon = null } countTotal() } watch(form, () => { countTotal() }) watch(() => state.isUseCoupon, () => { setActivatedCoupon() }) function submit() { if (couponList.length && !state.activatedCoupon) { alert('您有优惠券，确定不使用么') } console.log('submit!'); } </script> <template> <el-form :model="form" label-width="110px"> <el-form-item label="揽收费"> <el-input v-model="form.pickupFee"></el-input> </el-form-item> <el-form-item label="干线费"> <el-input v-model="form.zxFee"></el-input> </el-form-item> <el-form-item label="派送费"> <el-input v-model="form.deliveryFee"></el-input> </el-form-item> <el-form-item label="是否使用优惠券"> <el-switch v-model="state.isUseCoupon"></el-switch> </el-form-item> <template v-if="state.isUseCoupon"> <el-form-item label="优惠券列表" > <el-select v-model="form.couponId" placeholder="请选择优惠券" @change="setActivatedCoupon"> <el-option v-for="item in couponList" :key="item.id" :label="item.name" :value="item.id" ></el-option> </el-select> </el-form-item> <el-form-item label="折扣" > <span>{{ state.activatedCoupon ? state.activatedCoupon.discount : '未选中优惠券' }}</span> </el-form-item> </template> <el-form-item label="总价"> <span>¥：{{ form.total }}元</span> </el-form-item> <el-form-item> <el-button type="primary" @click="submit">提交</el-button> <el-button>取消</el-button> </el-form-item> </el-form> </template> 对于前端来说，MVC 的结构还是有些「重」了，实际应用上 Hooks 的形式会更加的适合。而且除了业务逻辑和视图逻辑可以通过 Hooks 进行解耦。由于前端重交互的特性，复杂或者高频的视图逻辑也可以封装成可复用的 Hooks。比如说组件全屏、鼠标点击/拖拽、分页等等。最后在前端 Hooks 时代到来之际，我们常常在想：怎么去写高质量、可复用的组件或者说怎么封装 Hooks 更加优雅。以下几点或许可以参考一二：在业务场景比较复杂时，尽量不要以「视图驱动」的方式（面向过程）开发；将用户交互引起的页面变动定义为视图逻辑，页面变动所依赖的数据实体变更定义为业务逻辑；业务逻辑和视图逻辑解耦，将业务逻辑封装成 Hooks；将复杂的或高频的视图逻辑封装成 Hooks；封装 Hooks 的时候结合 MVC 的理念：先找到需要暴露给外部进行消费的数据实体，然后定义实体的model部分，一般体现在利用入参进行实体的创建和初始化；然后将需要运算（并不局限于数学计算，dom 结构的变更，数据结构的变更，局部/全局状态的变更都属于运算）的部分定义成service暴露出去。

life.caoalmost 4 years

React 异步场景和一致性

背景相信大家知道 React 提出的一个核心理念： fn(state) = UI，只要输入是确定的，输出就是确定的。React 把函数式编程的思想带进了前端中。它解决了当时前端开发复杂化的痛点，这毫无疑问是革命性的，React 也因此而名声大噪。但在 fn(state) = UI 中的组件(即fn) 只能执行同步的代码，没有异步的概念，React 中不存在这样的公式： async fn(state) = UI 。这将会导致下面的一些问题异步时序问题在 React 中，我们请求数据最基本的方法是在组件第一次装载时使用 useEffect 和浏览器的fetch api，如下： function useRequest(queryFn, deps) { const [data, setData] = React.useState() // 定义一个state用于存储数据 const [isLoading, setIsLoading] = React.useState(false) // 定义一个state用于表示是否正在加载中 const run = () => { // 定义一个函数用于发起请求 setIsLoading(true) // 开始时设置加载状态为true setData(undefined) // 开始时将数据设置为undefined queryFn(...args) .then((data) => { setData(data) // 将返回的数据设置到state中 }) .catch(() => { setData(undefined) // 如果出现错误，将数据设置为undefined }) .finally(() => { setIsLoading(false) // 无论请求成功还是失败，都将加载状态设置为false }) } React.useEffect(() => { run() // 在组件挂载时发起请求 }, deps) return { data, isLoading, run } // 返回数据、状态和一个用于重新发起请求的函数 } 上述代码运行效果如下：在上述的场景中，我们常常会碰到的一个问题，当我们频繁修改参数时，查询结果显示抖动，且由于 run 方法是一个异步函数，它执行结束的时间是不可控的。如果 useEffect 依赖的 deps 在短时间内频繁变化时或频繁手动调用 run 方法时，很容易出现请求的竞态问题，即我们不能保证 data 是哪个 deps 请求的结果。 ps：我们常常用到的库例如 redux、useRequest 都存在着这个竞态问题。这在一些前端计算场景，尤其是涉及到和钱相关的，这一点特别需要注意。我们大多数项目都存在这个场景，特别是一些涉及表单筛选查询场景尤为明显。让我们试着解决有的小伙伴可能就想到了，当依赖(deps) 变化时取消之前的请求，只当最后一个的请求才生效不就好了么？我们将上面代码改动如下： // 将请求函数包装为可取消的Promise对象 const makeCancelable = (promise) => {...} function useRequest(queryFn, deps) { const [data, setData] = React.useState() const [isLoading, setIsLoading] = React.useState(false) const run = () => { setIsLoading(true) setData(undefined) const wrappedPromise = makeCancelable(queryFn()) // 使得Promise可以被取消 wrappedPromise .then((data) => { setData(data) }) .catch(() => { setData(undefined) }) .finally(() => { setIsLoading(false) }) return wrappedPromise.cancel } React.useEffect(() => { const cancel = run() return () => cancel() // 在组件卸载时取消请求 }, deps) return { data, isLoading, run } } 但还存在着一个问题，那就是当我们直接调用 run 方法时还是会导致上述的时序问题。所以我们需要将 run 方法替换成纯的、无副作用的 **refetch(不带参数且不会造成竞态)**方法。但此时 useRequest 只剩下查询能力不涉及增删改等包含突变的能力，所以我们将 useRequest 重命名为更符合语义的名字 useQuery ： function useQuery(queryFn, deps) { const [data, setData] = React.useState() const [isLoading, setIsLoading] = React.useState(false) const run = () => { setIsLoading(true) setData(undefined) const wrappedPromise = makeCancelable(queryFn()) wrappedPromise .then((data) => { setData(data) }) .catch(() => { setData(undefined) }) .finally(() => { setIsLoading(false) }) return wrappedPromise.cancel } React.useEffect(() => { const cancel = run() return () => cancel() }, deps) // 将run方法替换为不带参数且不会造成竞态的refetch方法 const refetch = () => { if (!isLoading) { run() } } return { data, isLoading, refetch } } 现在，我们已经可以做到 setData 只会被一个 run 函数调用。流程图如下：上述代码运行效果如下：在一些简单场景，这样做是可行的，但是当需要缓存数据和去除重复请求时就变得越来越困难。例如当参数一致时，当我们点击重试按钮，所有具有相同参数的组件都应当重新查询，而且目前多个组件之间数据是不共享的。下面我们来讲一下如何进行缓存和去重。缓存和去重经过我们修改，已经可以通过 deps(由于缓存需要将deps作为key，下面已将deps重命名为queryKey) 感知到 queryFn 查询函数的参数变化。接下来利用我们前面提到的函数式编程思想，当输入一致时，返回之前的缓存。我们可以利用传入的参数(queryKey) 作为缓存key，如果重复传入相同的 queryKey 时可以从缓存中取出之前的数据，相关实现如下，让我们先来看看代码吧： const queries = {} // 存储所有的查询实例 function getQuery(queryKey, queryFn) { const hash = JSON.stringify(queryKey) // 当 queryKey 一致时，返回已经生成过的查询实例 if (queries[hash]) return queries[hash] queries[hash] = { isLoading: false, data: undefined, // 存放着当前queryKey所有注册过的监听函数。 listeners: new Set(), refetch() { // 去除重复请求 if (this.isLoading) return // 更新状态 this.data = undefined this.isLoading = true // 通知各个hook已经开始进行请求了 this.listeners.forEach((cb) => cb()) queryFn() .then((data) => { this.data = data }) .catch(() => { this.data = undefined }) .finally(() => { this.isLoading = false // 通知各个hook的监听函数更新状态 this.listeners.forEach((cb) => cb()) }) }, } queries[hash].refetch = queries[hash].refetch.bind(queries[hash]) return queries[hash] } function useQuery(queryKey, queryFn) { const [, forceUpdate] = React.useReducer((num) => num + 1, 0) // 调用 getQuery 根据 queryKey 获取当前查询实例 const currentQuery = getQuery(queryKey, queryFn) React.useEffect(() => { currentQuery.refetch() currentQuery.listeners.add(forceUpdate) // 注册监听函数 return () => currentQuery.listeners.delete(forceUpdate) // 删除监听函数 }, [currentQuery]) return { data: currentQuery.data, isLoading: currentQuery.isLoading, refetch: currentQuery.refetch, } } 我们要明确一点，如果我们想要发起另一个请求，只允许改变传入的 queryKey 到 useQuery 中，这样我们才能感知到输入的变化。下面我们可以看看上述代码的实际运行效果：去重：当参数一致时，去除重复查询，可以看到点击下面重试按钮，参数相同的组件只有一个请求。缓存：当参数一致时，所有具有相同参数的组件都会都会复用一份缓存。无副作用：不管我们点击修改参数多么频繁，实际查询的结果都是当前参数的结果。现在我们在 react 中可以做到查询之间互不影响且没有交集，只要参数(queryKey)一致结果(query)就一致的纯函数了：请求库选型当然，上面只是一个简单的实现，如果你要在开发时避免上述的这些问题，在这里给大家推荐 ReactQuery 和 SWR 这两个React请求库，可以简化我们从服务器获取、缓存和同步数据方式。上述示例代码，其实就是我们对ReactQuery、SWR 的底层逻辑的实现。这两个库除了解决这些问题之外还考虑到了几乎所有的场景，而且做得非常好，甚至可以消除你对全局状态管理解决方案的需求。题外话在 React 10月13的 RFC: First class support for promises and async/await 中介绍了一个新的api use，主要是着手解决之前说的异步组件问题 async fn(state) = UI ，感兴趣的话了解一下相关文档 SWR https://github.com/vercel/swr RFC: First class support for promises and async/await https://github.com/reactjs/rfcs/pull/229

life.caoover 3 years

分支开发规范（可结合自己团队稍作修改）

分支开发规范 1.开发公约以 release 分支，作为仓库的主分支开发需求的分支，始于 release（从 release 拉新分支），终于 release（合入 release）提交 Merge Request 后，首先要保证自己 Code Reivew 自己的代码需求发布后，建立当前日期的Tag(版本经理或负责人操作) 2.分支命名规范友情提示：不要在公共分支上直接写代码，万一被公共分支被覆盖了，你的代码会丢（找回代码麻烦）开发阶段环境名称使用人员分支命名规范本地开发 feature/姓名_需求名_开始日期 (日期为MMDD) 开发联调功能测试 STG 开发同学测试同学 feature/姓名_需求名_开始日期或 stg如有多人同时开发同一个项目，请将自己分支合并到 stg 公共分支集成测试回归测试 PRE 测试同学产品/业务同学验收 feature/姓名_需求名_开始日期或 pre如有多人同时开发同一个项目，请将自己分支合并到 pre 公共分支待测试完毕，在发布日当天再将 feature 分支合并到 release，并将 release 分支发布到 PRE 环境，用于发布前最后的回归测试发布 PRD 统一使用 release 分支发布上线 3.开发新需求 git checkout release git pull origin release git checkout -b feature/yining_xxxx_0310 4.线上需求发布 a) 将自己的 feature 分支 rebase release（强烈建议要，后续如果回滚代码也不容易出错） b) 在 gitlab 上提 feature => release 分支的 Merge Request（无论是否 Code Reivew，都走 MR） c) 晚上发布窗口时，将 release 分支发布到 PRD 环境 Q：为什么要做 rebase release 操作呢？ A：这样一来，每次提的 Merge Request 里就不会带上别人的 commit。而 merge release => 你的分支，会将别人的 commit 带到你的 Merge Request 里，不利于比较代码 diff。更多参考：对 rebase 的详细介绍5.线上问题 hotfix git checkout release git pull origin release git checkout -b hotfix/yining_xxxx_0310 与开发新需求的流程一致，区别只在于开发、调试的分支名为 hotfix/姓名_需求名_开始日期

221

life.caoover 3 years

生产发布SOP

发布SOP 原则须知原则上，高峰期不做任何操作，包括：发代码、配置变更、灰度放量、开城规则变更，以及在微信公众平台上的操作（小程序放量、request / webview 域名配置、公众号安全域名变更等）如果有特殊情况，必须在高峰期变更，请说明原因并经过 leader 同意后才可操作 H5 与后端同一天晚上发布，小程序在后端发布后的次日晚上发布(审核原因) toC 小程序的发布，严禁直接全量上架，至少经过3批（可根据自己用户量决定）灰度放量此篇的目的规范发布操作流程，避免红线行为识别前端发布成功的标准，减少不必要的陪跑具备 oncall 意识，取代低效的等待方式发布操作流程知道如何线上验证，无法线上验证的需求务必拒绝发布明确发布的依赖顺序可以发布时，将 pre 环境最后一次验证的分支，发布到生产环境线上验证，一定要线上验证要看监控线上验证的标准如果有测试同学：完整流程可以交给测试去验，我们只要自己看下页面能不能打开如果是开发自测：必须要在真实APP上完整走一遍主流程，端内的页面不能用浏览器模拟器代替验证看监控的标准核心项目，发布完后必须要观察 15min 监控（看各自团队的监控基础设施比如埋点、监控日志）非核心项目，不做特殊要求，但必须线上验证红线行为发布后没有线上验证的，不管什么原因，一律违反SOP。核心项目发布后不看监控的，如果事后能从监控中发现异常，也属于违反SOP。发布后当晚有人反馈问题，而不去处理的，也是违反SOP。“处理”行为包括不限于：回滚、hotfix、降级，或沟通其他办法都算 “处理”并非一定变更生产环境，底线是有人反馈问题时，发布人要能应急响应开发计划里搭车，最后翻车的如何 oncall 手机畅通，不静音电脑 & VPN

164

life.caoover 3 years

Module Federation 在H5项目的实践

Module Federation 在H5项目的实践背景由于之前在开辟新业务时，组内需要短时间内开发6个中后台系统，这些系统 UI , UX 设计大体一致，前后端均由相同人员合作开发，开发前预想应有大量的模块是可以复用的，故需调研方便模块复用的前端代码管理方案，最终选取了 Webpack5 的最新特性 module federation（下文中简写为 MF ），并在项目实践落地。介绍 MF 是 webpack5 带来的新特性之一，是一种新的用于在应用程序之间共享代码的解决方案，并解决了共享模块的依赖共享问题。在 MF 中，每一个 webpack 构建都可以是 host (模块消费方)、 remote (模块提供方)，也可以同时是模块消费方与模块提供方，并可以通过简单的配置，实现远程模块的依赖共享, 而且可以加速项目的构建（配置共享依赖后 webpack 会将共享依赖包作为异步 chunk 处理加速项目构建）。对 webpack 熟悉的朋友们应该都知道插件的用法，使用 MF 就是使用 webpack5 内置的一个新的插件，它的构造函数有几个关键参数，见下表：参数名用途举例 name 容器名 app1 filename federation文件名 remoteEntry.js exposes 导出模块的映射 {//导出的模版需为类似 ./xxx 的相对路径，在消费方引用时即可使用容器名/xxx 进行引入'./App': './src/App',} shared 共享依赖的配置,通过简单的配置，即可实现项目间依赖的共享。 {react: { singleton: true }} 实战下面我们来看一个实际配置的例子 //app1的配置 new ModuleFederationPlugin({ name: "app1", remotes: { //通过ExternalTemplateRemotesPlugin实现的动态remote地址 //在项目入口处配置 window.app2Url = "http://localhost:3002" //等于 app2@http://localhost:3002/remoteEntry.js app2: "app2@[app2Url]/remoteEntry.js", }, shared: {react: {singleton: true}, "react-dom": {singleton: true}}, }) //app2的配置 new ModuleFederationPlugin({ name: 'app2', filename: 'remoteEntry.js', exposes: { './App': './src/App', }, shared: { react: { singleton: true }, 'react-dom': { singleton: true }}, }) app1 与 app2 的入口文档都是如下形式 import("./bootstrap"); 而两个项目中的 bootstrap.js 文件如下： import App from "./App"; import React from "react"; import ReactDOM from "react-dom"; ReactDOM.render(<App/>, document.getElementById("root")); app1 的 src/app.js 文件引用了 app2 的 App.js import React, {Suspense} from "react"; const RemoteApp = React.lazy(() => import("app2/App")); const App = () => { return ( <div> <div style={{ margin:"10px", padding:"10px", textAlign:"center", backgroundColor:"greenyellow" }}> <h1>App1</h1> </div> <Suspense fallback={"loading..."}> <RemoteApp/> </Suspense> </div>) } export default App; 可以看出 app2 将 app.js 暴露了出来作为模块提供方，app1 做为模块消费方引用了 app2 的组件（其实直接同步引入也可以，异步模块可以“同步引入”也是 MF 的魔法之一），并且双方都将入口文件修改成了异步加载的形式，并且都将 react , react-dom 设置为了共享依赖， app1 实际项目运行效果如下图：分析看完了运行效果，我们来简单分析一下项目的依赖结构，如下图：我们打开 app1 项目页面的 network 看板可以看到 app1 的项目加载逻辑如下： app1/main.js => app2/remoteEntry.js && app1/bootstrap.js => app2/react && app2/react-dom && app2/app.tsx 可以看到 app1 直接使用了 app2 的 react , react-dom 模块，“完美”的实现了模块的远端共享。原理浅析 webpack5 之前的 webpack 模块分类分类作用 webpack runtime webpack的运行时代码，负责处理模块加载与解析项目入口文件用户代码执行的入口同步chunk 直接import的模块异步chunk import()引入的模块模块加载逻辑加载模块并执行，执行过程中如果遇到静态 import，回到 1 如果遇到动态 import，前往 2 先把异步模块相关的异步模块加载到 modulesMap ，回到 1，递归加载模块开始执行用户代码在 webpack5 中，由于 MF 的出现，同步 chunk 与异步 chunk 又都可以分成两种，如下：分类作用同步非共享模块 import React from 'react'不做任何 MF配置的模块同步共享模块（webpack5特有） import React from 'react'同时把React设置为 MF的共享模块：new ModuleFederationPlugin({ shared: { react: { 一些配置 } }}) 异步本地模块 import ('./async-component')就是通过动态import引用的本地模块异步远端模块（webpack5特有） import('remote-app/async-component')通过动态import引用的远端(remote-app)模块加载逻辑发生了变化加载执行模块，处理解析模块中遇到的模块引入，执行过程中如果遇到静态 import如果这个模块是同步非共享模块，回到 1 如果这个模块是同步共享模块，前往 3 如果遇到动态 import如果这个模块是异步本地模块，前往 4 如果这个模块是异步远端模块，也前往 4 先把异步模块相关的异步模块加载到 modulesMap如果是来自 2.b，会初始化 shared scope ，用来处理依赖共享相关逻辑如果是来自 3.a，没有额外操作如果是来自 3.b，会利用 shared scope 来复用依赖，实现依赖共享那可能会有小伙伴疑问上面提到的 shared scope 是个什么东西，我们可以看看 webpack 的官方文档中的动态引入 MF 组件的代码实例： function loadComponent(scope, module) { return async () => { // Initializes the shared scope. Fills it with known provided modules from this build and all remotes await __webpack_init_sharing__('default'); const container = window[scope]; // or get the container somewhere else // Initialize the container, it may provide shared modules await container.init(__webpack_share_scopes__.default); const factory = await window[scope].get(module); const Module = factory(); return Module; }; } loadComponent('abtests', 'test123'); webpack_init_sharing 就是在初始化 shared scope ，我们再到上文例子中的 app1 项目中的 src/app.js 加入console.error(__webpack_init_sharing__);这段代码，然后再运行项目，就可以在开发工具面板里找到下面的这段 webpack runtime 代码： /* webpack/runtime/sharing */ (() => { __webpack_require__.S = {}; var initPromises = {}; var initTokens = {}; __webpack_require__.I = (name, initScope) => { if(!initScope) initScope = []; // handling circular init calls var initToken = initTokens[name]; if(!initToken) initToken = initTokens[name] = {}; if(initScope.indexOf(initToken) >= 0) return; initScope.push(initToken); // only runs once if(initPromises[name]) return initPromises[name]; // creates a new share scope if needed if(!__webpack_require__.o(__webpack_require__.S, name)) __webpack_require__.S[name] = {}; // runs all init snippets from all modules reachable var scope = __webpack_require__.S[name]; var warn = (msg) => (typeof console !== "undefined" && console.warn && console.warn(msg)); var uniqueName = "app1"; var register = (name, version, factory, eager) => { var versions = scope[name] = scope[name] || {}; var activeVersion = versions[version]; if(!activeVersion || (!activeVersion.loaded && (!eager != !activeVersion.eager ? eager : uniqueName > activeVersion.from))) versions[version] = { get: factory, from: uniqueName, eager: !!eager }; }; var initExternal = (id) => { var handleError = (err) => (warn("Initialization of sharing external failed: " + err)); try { var module = __webpack_require__(id); if(!module) return; var initFn = (module) => (module && module.init && module.init(__webpack_require__.S[name], initScope)) if(module.then) return promises.push(module.then(initFn, handleError)); var initResult = initFn(module); if(initResult && initResult.then) return promises.push(initResult['catch'](handleError)); } catch(err) { handleError(err); } } var promises = []; switch(name) { case "default": { register("react-dom", "17.0.2", () => (Promise.all([__webpack_require__.e("vendors-node_modules_react-dom_index_js"), __webpack_require__.e("webpack_sharing_consume_default_react_react")]).then(() => (() => (__webpack_require__(/*! ../node_modules/react-dom/index.js */ "../node_modules/react-dom/index.js")))))); register("react", "17.0.2", () => (Promise.all([__webpack_require__.e("vendors-node_modules_react_index_js"), __webpack_require__.e("node_modules_object-assign_index_js")]).then(() => (() => (__webpack_require__(/*! ../node_modules/react/index.js */ "../node_modules/react/index.js")))))); initExternal("webpack/container/reference/app2"); } break; } if(!promises.length) return initPromises[name] = 1; return initPromises[name] = Promise.all(promises).then(() => (initPromises[name] = 1)); }; })(); 代码有亿点点多，实际就是内部维护了一个 shared scope 名称与该 shared scope 下的模块名、模块版本、远端地址等信息的映射，并根据模块消费方与模块提供方的配置判断使用哪方的共享模块。使用场景个人总结了 MF 的几种使用场景，如下：首当其冲的当然是不同项目间的模块与组件的共享了，但是在实践过程个人发现一些公共模块可能并不适合使用 MF 来共享，可能更适合使用私有 npm 包的形式共享。但是如果有 A 项目需要使用 B 项目中的某些业务组件或某项目需要可以热更新的远端模块这样的场景，MF 可以说是有奇效。微前端，emp 就是一个以 MF 为基础实现的完善的微前端框架。得益于 MF 的远端共享与依赖共享机制，甚至我们可以自行通过对 MF 简单的封装来实现一个简单的微前端框架。实用技巧相信大家看完上面的部分，应该对 MF 有了一定的认知，下面介绍几种在实际运用中比较有用的技巧：远端动态加载 MF 模块 export async function loadRemoteComponent(config) { return loadScript(config).then(() => loadComponentByWebpack(config)) } function loadScript(config) { return new Promise((resolve, reject) => { const script = document.createElement('script'); script.src = config.url script.type = 'text/javascript' script.async = true script.onload = () => { console.log(`Dynamic Script Loaded: ${config.url}`) document.head.removeChild(script); resolve(); } script.onerror = () => { console.error(`Dynamic Script Error: ${config.url}`) document.head.removeChild(script) reject() } document.head.appendChild(script) }) } async function loadComponentByWebpack({ scope, module }) { // 初始化共享作用域，这将使用此构建和所有远程提供的已知模块填充它 await __webpack_init_sharing__('default') const container = window[scope] // 获取容器 // 初始化容器，它可以提供共享模块 await container.init(__webpack_share_scopes__.default); const factory = await window[scope].get(module); return factory(); } 但在个人实际使用中，发现了这种方式有共享模块无法同步加载的痛点（或者说依赖实现了 top-level-await 的运行环境），更适合在共享 vue react 等业务组件的场景下使用。我们来看下面的场景：假如 app2 项目想使用 app1 通过 MF 导出一个水印模块，那正常的使用应该如下： import waterMask from 'app1/waterMask'; waterMask.init(); 如果想远端引入，就要把代码修改成下面这样: import { loadComponent } from 'mf-util'; let waterMask = await loadRemoteComponent({ url: 'http://localhost:3001', scope: 'default', module: 'waterMask' }).default; waterMask.init() 乍一看问题也不大，但首先 top-level-await 就是一个兼容性很差的语法，而且目前 babel 等打包工具还没有完善的转译方案，所以如果项目兼容性要求高，就可以直接否决，其次如果这个远端加载的模块有一定的加载初始化顺序要求，可能要对原来的代码做破坏性的更改。动态 MF 远端地址这个其实在上文中的例子就有展示： //app1 wepback.js const ExternalTemplateRemotesPlugin = require('external-remotes-plugin'); plugins: [ new ModuleFederationPlugin({ name: "app1", remotes: { //通过ExternalTemplateRemotesPlugin实现的动态remote地址 //在项目入口处配置 window.app2Url = "http://localhost:3002" //等于 app2@http://localhost:3002/remoteEntry.js app2: "app2@[app2Url]/remoteEntry.js", }, shared: {react: {singleton: true}, "react-dom": {singleton: true}}, }), new ExternalTemplateRemotesPlugin(), ... ], //app1 index.js window.app2Url = "http://localhost:3002" 安装配置 external-remotes-plugin 插件,将 remotes 配置里的 url 地址修改成 app2@[xxx]/remoteEntry.js 的形式，然后在入口文件最上面通过设置 window.xxx 就可以实现了。远端模块类型问题假如是用了 typescript 的项目，引入远端模块后模块的类型问题也是个头疼的点，下面这段代码（主要参考于 mf-lite 项目，感谢开源大佬们的贡献）就可以帮助你生成 MF模版的 d.ts 类型声明文件（mf.config是项目中抽取出的MF配置，具体使用可以调用 emitMfExposeDeclaration 自由发挥）： import * as os from 'os'; import * as path from 'path'; import fs from 'fs-extra'; import { createRequire } from 'module'; import { execa, ExecaChildProcess } from 'execa'; import { ModuleDeclarationKind, Project, SyntaxKind } from 'ts-morph'; import { cwd } from 'process'; import mfConfig from '../mf.config/index.js'; const require = createRequire(import.meta.url); const { writeFile, remove, ensureDir } = fs; export const runCommand = async ( command: string, args?: string[], path?: string, ): Promise<ExecaChildProcess> => { let p = path; if (!p) { p = cwd(); } if (!args) { // \s 匹配任何空白字符，包括空格、制表符、换页符 // eslint-disable-next-line no-param-reassign [command, ...args] = command.split(/\s+/); } return execa(command, args, { cwd: p, stdio: 'inherit', }); }; export interface FileOptions { // 声明文件路径 path: string; // 声明文件模块名称 moduleName: string; } export const bundleModuleDeclare = (fileOptions: FileOptions[]) => { const project = new Project(); const content: string[] = []; fileOptions.forEach(file => { // 添加源代码 const source = project.addSourceFileAtPath(file.path); // 遍历每一个子节点，如果是 SyntaxKind.DeclareKeyword（即 declare 关键词），进行文本替换 source.forEachDescendant(item => { if (item.getKind() === SyntaxKind.DeclareKeyword) { // 删除即可, 需要判断是不是第一个节点，否则会报异常 item.replaceWithText(item.isFirstNodeOnLine() ? 'export' : ''); } }); // 备份根节点 const baseStatements = source.getStructure().statements; // 移除现存的所有节点 source.getStatements().forEach(res => res.remove()); // 创建一个 module declaration，将上面备份的根节点插入之 source.addModule({ name: `'${file.moduleName}'`, declarationKind: ModuleDeclarationKind.Module, hasDeclareKeyword: true, statements: baseStatements, }); // 格式化代码 source.formatText(); // 补充一些注释 content.push(`// module name: ${file.moduleName}\n\n`); content.push(source.getText()); content.push('\n'); }); return content.join(''); }; export interface BundleFileConfig { // 入口文件路径 entryPath: string; // 输出路径 outputPath: string; } export const bundleTsDeclaration = async (entries: BundleFileConfig[]) => { // 最大并行工作数目为 cpu 核心数 - 1 const maxWorkSize = os.cpus().length - 1; while (entries.length > 0) { const runningItems = entries.splice(0, maxWorkSize); await Promise.all( runningItems.map(item => { const { entryPath, outputPath } = item; return runCommand( path.resolve( require.resolve('dts-bundle-generator'), '../bin/dts-bundle-generator.js', ), [ entryPath, '--out-file', outputPath, '--project', path.resolve(cwd(), 'tsconfig.json'), '--no-banner', ], ); }), ); } }; export const emitMfExposeDeclaration = async ( appConfig: any, baseUrl: string, ) => { // 增加临时缓存文件，用来打包每个小 bundle await ensureDir(path.resolve(baseUrl, '.cache')); const entries: (BundleFileConfig & { name: string })[] = []; for (const expose of Object.keys(appConfig.exposes)) { // 只处理 module 类型 entries.push({ name: expose.replace(/^[./]*/, ''), entryPath: appConfig.exposes[expose], outputPath: path.resolve( baseUrl, '.cache', `${expose.replace(/^[./]*/, '')}.d.ts`, ), }); } // 并行打包 await bundleTsDeclaration(entries.slice()); // 合并上面的所有小 bundle const content = bundleModuleDeclare( entries.map(res => { return { path: res.outputPath, moduleName: `${appConfig.name}/${res.name}`, }; }), ); await writeFile(path.resolve(baseUrl, 'exposes.d.ts'), content); await remove(path.resolve(baseUrl, '.cache')); }; emitMfExposeDeclaration(mfConfig, path.resolve(cwd(), './dist')); Vite 项目中使用 MF 推荐使用 vite-plugin-federation 这款 vite 插件，这款插件可以实现 vite 与 webpack 项目间的 MF 模块复用，但是实现还是有赖于 top-level-await 语法特性，目前还有一些 MF 配置项尚未同步，具体使用各位大佬可以查看该插件文档～总结本文就是 Module Federation 在货拉拉汽销中后台的全部实践经验了，如有不足或异议，欢迎各位大佬评论区指出. 引用： MF没有魔法仅仅是异步chunk 深入探索Webpack5之Module Federation的“奇淫技巧”

123

life.caoalmost 4 years

从bundle产物中分析webpack5 Module Federation

从bundle产物中分析webpack5 Module Federation 背景我们启动了新的项目，技术选型使用到了webpack5 Module Federation，因此我对该新特性做了一番研究，本文从bundle中来分析webpack是如何实现remote component调用以及package的共享。带着这两个问题开启咱们探索之旅吧案例配置展示配置之前先解释一下host和remote的关系，从微前端角度来解释，host就是基座。remote就是子应用 Remote new ModuleFederationPlugin({ // 子应用名称 name: 'home', // 获取子应用入口 filename: 'remoteEntry.js', exposes: { // 将这两个组件共享出去 './Content': './src/components/Content', './Button': './src/components/Button', }, shared: { // 与基座共享一个package vue: { singleton: true, }, }, }) Host new ModuleFederationPlugin({ // 基座名称 name: 'layout', remotes: { // 连接子应用 home: 'home@http://localhost:3002/remoteEntry.js', }, shared: { // 与子应用共享一个package vue: { singleton: true, }, }, }) Host的./src/main.js import { createApp, defineAsyncComponent } from 'vue'; import Layout from './Layout.vue'; const Content = defineAsyncComponent(() => import('home/Content')); const Button = defineAsyncComponent(() => import('home/Button')); const app = createApp(Layout); app.component('content-element', Content); app.component('button-element', Button); app.mount('#app'); bundle分析看构建后的产物，需要做一些公共方法和变量的解释，这边会更利于你的阅读 __webpack_modules__，存储的是module，例如webpack配置的entry __webpack_require__，从__webpack_modules__中加载模块 webpack_require.e，动态加载模块，比如，import('./Button') webpack_require.o，判断对象中是否有该元素，用的是hasOwnProperty该方法 webpack_require.d，在对象上定义getter方法，用的是 defineProperty webpack_require.S，存储的共享package get方法 webpack_require.l 加载共享package 并将 package 注入到远程组件内 remote的共享组件的入口 remoteEntry.js // .... // module入口 var __webpack_modules__ = { 'webpack/container/entry/home': (__unused_webpack_module, exports, __webpack_require__) => { // remote 向外提供的组件 var moduleMap = { './Content': () => { return Promise.all([ __webpack_require__.e('webpack_sharing_consume_default_vue_vue'), __webpack_require__.e('src_components_Content_vue-_b1070'), ]).then(() => () => __webpack_require__('./src/components/Content.vue')); }, './Button': () => { return Promise.all([ __webpack_require__.e('webpack_sharing_consume_default_vue_vue'), __webpack_require__.e('src_components_Button_js-_e56a0'), ]).then(() => () => __webpack_require__('./src/components/Button.js')); }, }; // host 通过该方法获取 ‘./Content’ ‘./Button’ 组件 var get = (module, getScope) => { __webpack_require__.R = getScope; getScope = __webpack_require__.o(moduleMap, module) ? moduleMap[module]() : Promise.resolve().then(() => { throw new Error('Module "' + module + '" does not exist in container.'); }); __webpack_require__.R = undefined; return getScope; }; // host 将共享的package注入到remote，便于 ‘./Content’ ‘./Button’获取 package var init = (shareScope, initScope) => { if (!__webpack_require__.S) return; var name = 'default'; var oldScope = __webpack_require__.S[name]; if (oldScope && oldScope !== shareScope) throw new Error( 'Container initialization failed as it has already been initialized with a different share scope', ); __webpack_require__.S[name] = shareScope; return __webpack_require__.I(name, initScope); }; // 给 webpack/container/entry/home 模块添加 getter，get 和 init 方法 // getter 是 __webpack_require__.d 实现的 __webpack_require__.d(exports, { get: () => get, init: () => init, }); }, }; // ... // 加载上面的 webpack/container/entry/home module var __webpack_exports__ = __webpack_require__('webpack/container/entry/home'); // 将 webpack/container/entry/home module导出的两个方法 get 和 init 挂载到 home 上 home = __webpack_exports__; 上面是remote的入口文件 remoteEntry.js，它主要干了这些事 window 挂在 home 变量，home是 remote和host沟通的桥梁加载 webpack/container/entry/home，将 remote的Content、Button 组件get和共享package注入方法暴露出去先简单介绍上面两个，其实已经将咱们的问题解释了三分之一了（如何实现remote component调用以及package的共享）。咱们接着看看，Host干了什么 Host 入口 main Host这边做的比较多，咱们从入口文件一段段代码分析 // host 模块入口 var __webpack_modules__ = { // 入口module 入口 './src/index.js': (__unused_webpack_module, __unused_webpack_exports, __webpack_require__) => { __webpack_require__ .e(/* import() */ 'src_main_js') .then(__webpack_require__.bind(__webpack_require__, './src/main.js')); }, // remote module 的入口其实就是 remoteEntry 'webpack/container/reference/home': (module, __unused_webpack_exports, __webpack_require__) => { var __webpack_error__ = new Error(); module.exports = new Promise((resolve, reject) => { // 防止重复加载 if (typeof home !== 'undefined') return resolve(); // 使用jsonp加载 remoteEntry.js 并执行 remoteEntry.js __webpack_require__.l( 'http://localhost:3002/remoteEntry.js', event => { if (typeof home !== 'undefined') return resolve(); // remote加载或者执行失败回调异常抛出 var errorType = event && (event.type === 'load' ? 'missing' : event.type); var realSrc = event && event.target && event.target.src; __webpack_error__.message = 'Loading script failed.\n(' + errorType + ': ' + realSrc + ')'; __webpack_error__.name = 'ScriptExternalLoadError'; __webpack_error__.type = errorType; __webpack_error__.request = realSrc; reject(__webpack_error__); }, 'home', ); // 返回 remote export === home }).then(() => home); }, }; // .... var __webpack_exports__ = __webpack_require__('./src/index.js'); 上面代码块加载入口模块 ./src/index.js ,加载这个模块主要干了这些事执行__webpack_require__.e(/* import() */ 'src_main_js')主要去加载共享package vue、remote remoteEntry.js和src_main_js ，并将 vue 的get方式注入到 remote 中，并将 Button和Content 组件的get方法暴露到 host中，具体看代码实现加载共享package vue register("vue", "3.2.41", () => __webpack_require__ // 远程加载vue组件，并将 vue内的模块通过 ./node_modules/@vue/runtime-dom/dist/runtime-dom.esm-bundler.js 挂在到 _webpack_module_ 中 .e("vendors-node_modules_vue_runtime-dom_dist_runtime-dom_esm-bundler_js") .then( () => () => // 从 _webpack_module_ 中获取 vue __webpack_require__( "./node_modules/@vue/runtime-dom/dist/runtime-dom.esm-bundler.js" ) ) ); 加载 remoteEntry.js & 将 vue 的get方式注入到 remote 中 initExternal('webpack/container/reference/home'); var initExternal = id => { // id: webpack/container/reference/home // ... try { // __webpack_require__(id) 直接从 __webpack_modules__ 中获取，可以看看上 __webpack_modules__['webpack/container/reference/home']加载 var module = __webpack_require__(id); if (!module) return; // var initFn = module => // module: remoteEntry.js 抛出来的全局home // module.init === home.init, home.init 将共享package的vue注入到remoteEntry中 module && module.init && module.init(__webpack_require__.S[name], initScope); // remoteEntry加载完成之后，执行注入 if (module.then) return promises.push(module.then(initFn, handleError)); var initResult = initFn(module); if (initResult && initResult.then) return promises.push(initResult['catch'](handleError)); } catch (err) { handleError(err); } }; 加载 host的 ./src/main.js // jsonp形式加载 ./src/main.js __webpack_require__.f.j = (chunkId, promises) => { var url = __webpack_require__.p + __webpack_require__.u(chunkId); __webpack_require__.l(url, loadingEnded, 'chunk-' + chunkId, chunkId); }; // 加载完成之后，将 ./src/main.js 放到 __webpack_module_中 // webpackChunk_vue3_demo_layout.push 实现了将 ./src/main.js 放到 __webpack_module_中 (self['webpackChunk_vue3_demo_layout'] = self['webpackChunk_vue3_demo_layout'] || []).push([ ['src_main_js'], { './src/main.js': (__unused_webpack_module, __webpack_exports__, __webpack_require__) => {}, }, ]); Button和Content 组件的get方法暴露到 host中其实这个方式分析 remote remoteEntry.js 已经提到了，就是home.get 这个方法，如何去获取的，咱们继续往下面分析执行完__webpack_require__.e(/* import() */ 'src_main_js')之后，继续执行后面的 .then(__webpack_require__.bind(__webpack_require__, './src/main.js')) 这其实就是去加载 ./src/main.js 模块并执行，也就是去执行vue那部分代码了，里面就涉及到了加载 remote的Button 和Content 加载 remote 的 Button const Button = (0, runtime_dom_esm_bundler_js_.defineAsyncComponent)(() => // 下载远程的组件 Button，这里实际执行的是 __webpack_require__.f.remotes 方法 __webpack_require__ .e(/* import() */ 'webpack_container_remote_home_Button') .then( // 加载 Button 组件 __webpack_require__.t.bind(__webpack_require__, 'webpack/container/remote/home/Button', 23), ), ); const app = (0, runtime_dom_esm_bundler_js_.createApp)(Layout); app.component('content-element', Content); 看看 webpack_require.f.remotes 如何下载 remote Button先通过 webpack/container/reference/home module查找到 remoteEntry.js export，也就是上面说的 home,包含get和init方法然后通过 home.get('./Button') 获取对应的remote Button，并将它缓存下下来 /* webpack/runtime/remotes loading */ (() => { var chunkMapping = { webpack_container_remote_home_Button: ['webpack/container/remote/home/Button'], }; var idToExternalAndNameMapping = { 'webpack/container/remote/home/Button': [ 'default', './Button', 'webpack/container/reference/home', ], }; // chunkId: webpack_container_remote_home_Button __webpack_require__.f.remotes = (chunkId, promises) => { if (__webpack_require__.o(chunkMapping, chunkId)) { chunkMapping[chunkId].forEach(id => { // id: webpack/container/remote/home/Button var getScope = __webpack_require__.R; if (!getScope) getScope = []; // data: ['default', './Button', 'webpack/container/reference/home']; var data = idToExternalAndNameMapping[id]; if (getScope.indexOf(data) >= 0) return; getScope.push(data); if (data.p) return promises.push(data.p); var handleFunction = (fn, arg1, arg2, d, next, first) => { try { var promise = fn(arg1, arg2); if (promise && promise.then) { var p = promise.then(result => next(result, d), onError); if (first) promises.push((data.p = p)); else return p; } else { return next(promise, d, first); } } catch (error) {} }; var onExternal = (external, _, first) => external ? handleFunction(__webpack_require__.I, data[0], 0, external, onInitialized, first) : onError(); var onInitialized = (_, external, first) => handleFunction(external.get, data[1], getScope, 0, onFactory, first); var onFactory = factory => { data.p = 1; __webpack_require__.m[id] = module => { module.exports = factory(); }; }; handleFunction(__webpack_require__, data[2], 0, 0, onExternal, 1); }); } }; })(); 总结用一张图来解释一下，package如何共享、remote component 如何加载的

life.caoalmost 4 years

Tailwind CSS的实践和流程分析

Tailwind CSS的实践和流程分析背景介绍之前项目中遇到使用Tailwind CSS和CSS Variables相关问题，在解决问题的过程中初步看了下Tailwind CSS的流程，跟大家分享下～众所周知，Tailwind CSS可以通过CL、PostCSS、CDN的方式来使用，这篇分享主要是以PostCSS插件的使用方式来讲述的。不了解Tailwindcss的同学查看官方文档Get started with Tailwind CSS。在开始这篇文章之前，请大家先思考几个问题： Tailwind CSS是动态编译出CSS样式，还是统一生成CSS样式再TreeShaking掉多余的classNames？ TSX文件中的classNames最终是编译成JSX函数内参数的，那这些classNames是如何被Tailwind CSS插件检测到并进行编译转换呢？ Tailwind CSS的类名和对应的样式是怎样生成的？入口配置首先做好配置。增加tailwind.config.js/postcss.config.js文件，并在主css文件中引入tailwind。 // tailwind.config.js module.exports = { content: ['./src/**/*.{js,jsx,ts,tsx}'], theme: { extend: {}, }, } // main.css @tailwind base; @tailwind components; @tailwind utilities; // postcss.config.js module.exports = { plugins: { tailwindcss: {}, autoprefixer: {}, }, } tailwind.config.js中的content: ['./src//*.{js,jsx,ts,tsx}']的字段表示将会扫描的文件路径，检测是否存在匹配的Tailwind CSS className**值，如果有的话，再做相应处理。 // 声明Tailwind CSS插件 module.exports = function tailwindcss () { postcssPlugin: 'tailwindcss', plugins: [ function (root, result) { let context = setupTrackingContext(configOrPath) // ...省略其他代码 processTailwindFeatures(context)(root, result) } ] } 在创建tailwindcss插件的时候，setupTrackingContext函数主要是创建了上下文实例： context: { classCache, candidates, changedContent }classCache：用来缓存className值； candidates：正则匹配出来的字符串，比如import render classNames等； candidateRuleMap: 保存各个关键字（比如font, text等）的处理函数及相关数据； changedContext: 通过fast-glob函数查找到tailwind.config.js中content对应的文件路径，并读取文件内容。 Tailwind特性处理接下来是processTailwindFeatures函数，主要在这个函数中做了很多特性处理： expandTailwindAtRules partitionApplyAtRules evaluateTailwindFunctions substituteScreenAtRules .etc 这里我们只看expandTailwindAtRules函数，它主要做了以下3件事：匹配Tailwind CSS类名生成CSS样式调用postcss.process方法生成Rule、Decl等AST节点匹配Tailwind CSS类名以App.vue文件为例 <template> <div id="app"> <h1 class="text-3xl font-bold underline"> Hello world! </h1> </div> </template> <script> export default { name: 'App', data() { return { }; }, created() { }, destroyed() { } }; </script> getClassCandidates读取到了‘text-3xl font-bold underline’ 这3个Tailwind CSS的className值。参数content即App.vue文件内容，通过\n换行符，逐行匹配。 extractor通过正则匹配到[ 'text-3xl', 'font-bold', 'underline' ]，并保存到candidates中： candidates: new Set(['text-3xl', 'font-bold', 'underline']) function getClassCandidates(content, extractor, candidates, seen) { for (let line of content.split("\n")){ line = line.trim(); let extractorMatches = extractor(line).filter((s)=>s !== "!*"); let lineMatchesSet = new Set(extractorMatches); for (let match1 of lineMatchesSet){ candidates.add(match1); } extractorCache.get(extractor).set(line, lineMatchesSet); } } getExtractor函数 export function defaultExtractor(context) { let patterns = Array.from(buildRegExps(context)) return (content) => { /** @type {(string|string)[]} */ let results = [] for (let pattern of patterns) { results.push(...(content.match(pattern) ?? [])) } return results.filter((v) => v !== undefined).map(clipAtBalancedParens) } } 生成CSS样式 Tailwind升级到3这个大版本后，是动态生成CSS样式的。它提供了很多【关键字-处理函数】【主题key-值】这样的映射表（详见corePlugins.js）再通过内置的处理函数fn1 fn2，查找某个主题的值，比如：具体可看corePlugins.js/defaultConfig.stub.js。 // 关键字key-处理函数utilities { text: [ [ { options: { values: { 3xl: ['1.875rem', { lineHeight: '2.25rem' } ] }, }, layer: 'utilities' // base utilities }, function fn1() {} ], [ {}, function fn2() {} ], ] } //主题key-value { fontSize: { base: ['1rem', { lineHeight: '1.5rem' }], '3xl': ['1.875rem', { lineHeight: '2.25rem' }], // ... }, } 从第一步拿到candidates后，再通过generateRules来生成css样式。那到底是怎样生成的呢？ function generateRules(candidates, context) { let allRules = []; for (let candidate of candidates){ // ...省略代码 let matches = Array.from(resolveMatches(candidate, context)); // ...省略代码 context.classCache.set(candidate, matches); allRules.push(matches); } // ...省略代码 return allRules.flat(1).map(([{ sort , layer , options }, rule])=>{ // ...省略代码 return [ sort | context.layerOrder[layer], rule ]; }); } 其中，resolveMatches函数承担了这一工作。以text-3xl为例，通过'-'分隔符将其变换成['text', '3xl']，再根据Tailwind提供的处理函数candidateRuleMap.get('text')，生成 .text-3xl { font-size: '1.875rem', line-height: '2.25rem' } 黄色部分是通过dlv函数从defaultConfig.stub.js获取到的默认值： // tailwindConfig: { theme: { screens: {}, fontSize: {] } } dlv(tailwindConfig, ['theme', 'fontSize', ...[]], undefined) 生成AST节点最后再调用PostCSS方法生成AST节点，这样就可以配合其他PostCSS插件，比如autoprefixer，一起来使用了。 export default function parseObjectStyles(styles) { if (!Array.isArray(styles)) { return parseObjectStyles([styles]) } return styles.flatMap((style) => { return postcss([ postcssNested({ bubble: ['screen'], }), ]).process(style, { parser: postcssJs, }).root.nodes }) } 总结最后我画了一个简图来辅助梳理思路。看到这里，你应该能回答文章开头的几个问题了吧？ Q: Tailwind CSS是动态编译出CSS样式，还是统一生成CSS样式再TreeShaking掉多余的classNames？ A: 最新版本的Tailwind CSS是动态编译出CSS样式的。 Q: TSX文件中的classNames最终是编译成JSX函数内参数的，那这些classNames是如何被Tailwind CSS插件检测到并进行编译转换呢？ A: 以main.css文件为契机，执行PostCSS插件提供的函数，再通过fast-glob读取文件内容，进而通过正则来进行匹配。 Q: Tailwind CSS的类名和对应的样式是怎样生成的？ A: 通过不同的映射，根据不同的默认值和对应的处理函数，生成不同的样式。具体可看corePlugins.js/defaultConfig.stub.js

life.caoalmost 4 years

H5实现pdf和excel在线预览

H5实现pdf和excel在线预览需求背景经线下调研发现，在开具电子普票人群中99%以上存在“开票时填财务邮箱接收电子发票/行程单，方便进行下载、对账”的使用场景。如果能够支持开票人将电子发票分享给微信好友，可带来新用户数和订单数增长。分享后的电子发票页支持在线预览发票、行程单、费用明细等文件，文件类型包含：图片、PDF、EXCEL 依赖的开源库 Xlsx Pdf-dist html2canvas Excel在线预览实现实现步骤 1、设置请求响应类型responseType: arraybuffer，请求接口将二进制文件流转为arraybuffer格式 2、XLSX.readFile方法解析数据，获取Worksheet工作表 3、XLSX.utils.sheet_to_html回调方法获取生成的html，渲染html到容器 4、将渲染之后的html，通过html2canvas绘制成canvas，canvas.toDataURL获取到base64图片路径 5、加载base64图片功能截图代码演示 /** * 读取文件流并输出html */ readExcelFile(url) { axios.get(url, { responseType: 'arraybuffer' }) .then((res)=>{ // 解析数据 let readFile = XLSX.readFile(res.data) // 获取工作表 let { Worksheet } = readFile.Sheets var container = document.getElementById("tavolo"); // 获取对应table html，渲染至容器 container.innerHTML = XLSX.utils.sheet_to_html(Worksheet); // 绘制canvas，生成图片 this.drawCanvas() }).catch( err =>{ console.log(err) }) }, /** * 绘制canvas图片 */ drawCanvas() { let canvasDom = document.getElementById('tavolo') (window.html2canvas || html2canvas)(canvasDom, { useCORS: true, scale: isIOS() ? 1 : 2, // 区别ios、安卓，设置缩小比例 scrollX: 0, scrollY: 0, allowTaint: true }).then(function(canvas) { const imgData = canvas.toDataURL("image/jpeg", 1.0); // base64 url ImagePreview({ // 预览图片 images: [ imgData ], closeable: true, maxZoom: 10, closeIconPosition: 'left', closeIcon: require('@/assets/images/ico_preview_close.png'), transition: 'van-slide', }) showLoading({ show: false }) }); } Excel在线预览补充说明 1、由于生成canvas大小限制问题，iOS需单独控制缩小比例，不同的浏览器内核对 canvas 的处理策略不一样，它可能超出了 Safari 浏览器的限制，而 chrome 是没有这个限制，所以安卓手机是正常的。 2、chrome、Firefox、Safari 等浏览器对 canvas 的总内存占用限制、单个 canvas 的限制（如 width、height、像素密度）不尽相同。在大量使用 canvas 时没有注意及时回收，导致了他在 chrome 测试没问题的代码，Firefox 中完全没有反应，在 Safari 中报错。 3、引入方式统一为：import * as XLSX from 'xlsx/xlsx.mjs'，避免xlsx高低版本差异 4、html2canvas需要加上scrollX: 0以及scrollY: 0，避免绘制的起点不同，出现空白间距 5、canvas所属dom元素尽量加大宽高值，否则会出现布局错乱，再利用translate3d偏移就可以使canvas不会出现在可视区域 6、html2canvas版本固定为v1.0.0-rc.4，减少兼容问题 Pdf在线预览实现实现步骤 1、组件挂载时，初始化pdfjs-dist sdk 2、请求获取pdf文件，返回数据格式建议为：二进制文件流(需通过Buffer转成base64)或者base64串(首选) 3、pdfjs-dist根据base64获取pdf信息，如pdf页数numPages，从而绘制分页canvas 4、由canvas获取base64路径，加载图片功能截图代码演示 /** * 生成canvas * @params {pdf} pdf pdf对象 * @params {Number} page pdf当前页数 */ async drawCanvas(pdf, page) { let canvas = document.createElement('canvas'); let page = await pdf.getPage(page) //调用getPage方法传入当前循环的页数,返回一个page对象 let ctx = canvas.getContext('2d') let dpr = window.devicePixelRatio || 1 let bsr = ctx.webkitBackingStorePixelRatio || ctx.mozBackingStorePixelRatio || ctx.msBackingStorePixelRatio || ctx.oBackingStorePixelRatio || ctx.backingStorePixelRatio || 1 let ratio = dpr / bsr let viewport = page.getViewport(screen.availWidth / page.getViewport(1).width) canvas.width = viewport.width * ratio canvas.height = viewport.height * ratio canvas.style.width = viewport.width + 'px' canvas.style.height = viewport.height + 'px' ctx.setTransform(ratio, 0, 0, ratio, 0, 0) let renderContext = { canvasContext: ctx, viewport: viewport } await page.render(renderContext) this.base64List.push(canvas.toDataURL('image/png')) }, /** * 绘制canvas，预览pdf * @params {String} stream 文件base64 */ async showPdf (stream) { try { let decodedBase64 = window.atob(stream) //使用浏览器自带的方法解码 let pdf = await PDFJS.getDocument({ data: decodedBase64, cMapUrl: "https://unpkg.com/pdfjs-dist@2.2.228/cmaps/", cMapPacked: true }) //返回一个pdf对象 let { numPages } = pdf._pdfInfo for (let i = 1; i <= numPages; i++) { this.drawCanvas(pdf, i) } this.previewImages() } catch (err) { console.log(err) } } Pdf在线预览补充说明 1、由于一些网络通讯协议的限制，使用 window.btoa() 方法对base64数据进行编码后返回给客户端。所以需window.atob解码之后，才能使用 2、pdfJs执行参数中cMapUrl，为pdf生成时所需的字体文件cdn链接，尽量勿使用国外cdn，如jsdelivr.net，避免服务器不稳定等因素导致文件加载失败，pdf绘制失败，最好是下载对应文件放置公司cdn服务再引入 3、base64 url获取需等page.render执行之后才可以获取 4、pdfjs-dist采用版本: 2.0.943，避免编译错误问题

164

life.caoabout 4 years

小程序优化首包大小—分包异步化

小程序优化首包大小—分包异步化理论微信官方建议性能优化中关于代码体积优化有以下 4 点：合理使用分包加载非主包资源都可以放到分包中，保证主包资源最快时间让用户可以访问，分包的资源可以按照重要性开启分包预下载。避免非必要的全局自定义组件和插件如题，非必要（组件功能单一、只有 1 个页面引入等）就不要把组件写在主包，拆进分包。多个分包都同时引用的资源，放在分包里则不合适，分包没法直接访问另一个分包的资源，除非两个分包都已经加载过了。这个问题可以使用「分包异步化」解决，这是本文重点，下文再表。控制代码包内的资源文件图片、字体文件建议尽量都走 CDN，小程序的 WXSS 中图片资源没法访问本地路径，也是建议把图片资源放在 CDN 上。及时清理无用代码和资源实践控制小程序代码包大小主要几个手段：静态资源，能走 CDN 的，全部走 CDN。能分包的页面或者组件，全部放到分包里面去，主包只留不能分的。如果资源一定要在主包引用且大小不可控，那就使用「分包异步化」或者「分包插件异步化」来处理。「分包异步化」和「分包插件异步化」两者的选择建议：如果用的是第三方编译的小程序框架，比如 Uniapp，那就用不上「分包异步化」，等它支持分包插件异步化和分包异步化写法差不多，坏处是需要发一个微信小程序插件，好处是小程序是跨端编译到其它端也可以走插件这一套逻辑。最终首包由1.8M减到1.2M左右

340

life.caoabout 4 years

徒手开Webpack 5系

徒手开Webpack 5系背景最近项目都开始切Webpack5，想徒手开一个前提随手打开过 webpack 的官网随手打开过 babel 的官网简单了解过 tapable 的功能简单了解过 node 是干嘛的简单写过点 js 执行过 npm run build （这一步很关键，所以我直接加粗 + 标红）版本 5.73.0 示例详情 1.目录结构 . ├── main │ └── index.js ├── package-lock.json ├── package.json ├── src │ ├── div.js │ ├── mul.js │ ├── sub.js │ └── sum.js ├── webpack.config.js 2.文件内容 sum.js function sum(num1, num2) { return num1 + num2 } module.exports = { sum } sub.js function sub(num1, num2) { return num1 - num2 } module.exports = { sub } mul.js function mul(num1, num2) { return num1 * num2 } module.exports = { mul } div.js function div(num1, num2) { return num1 / num2 } module.exports = { div } index.js const { sum } = require("../src/sum.js"); const { sub } = require("../src/sub.js"); const { mul } = require("../src/mul.js"); const { div } = require("../src/div.js"); const sumResult = sum(50, 50); const subResult = sub(50, 50); const mulResult = mul(50, 50); const divResult = div(50, 50); console.log({ sumResult, subResult, mulResult, divResult, }); webpack.config.js const webpack = require("webpack"); const path = require("path"); module.exports = { entry: "./main/index.js", output: { path: path.resolve(__dirname, "dist"), filename: "[name].bundle.js", }, mode: "development", devtool: "source-map", module: { rules: [ { test: /\.m?js$/, exclude: /node_modules/, use: { loader: "babel-loader", options: { presets: ["@babel/preset-env"], }, }, }, ], }, plugins: [ new webpack.BannerPlugin({ banner: "webpack! webpack! webpack! webpack! webpack!", footer: true, }), ], }; 3.打包产物 (() => { var __webpack_modules__ = { "./src/div.js": (module) => { function div(num1, num2) { return num1 / num2; } module.exports = { div: div, }; }, "./src/mul.js": (module) => { function mul(num1, num2) { return num1 * num2; } module.exports = { mul: mul, }; }, "./src/sub.js": (module) => { function sub(num1, num2) { return num1 - num2; } module.exports = { sub: sub, }; }, "./src/sum.js": (module) => { function sum(num1, num2) { return num1 + num2; } module.exports = { sum: sum, }; }, }; var __webpack_module_cache__ = {}; function __webpack_require__(moduleId) { var cachedModule = __webpack_module_cache__[moduleId]; if (cachedModule !== undefined) { return cachedModule.exports; } var module = (__webpack_module_cache__[moduleId] = { exports: {}, }); __webpack_modules__[moduleId](module, module.exports, __webpack_require__); return module.exports; } (() => { var _require = __webpack_require__("./src/sum.js"), sum = _require.sum; var _require2 = __webpack_require__("./src/sub.js"), sub = _require2.sub; var _require3 = __webpack_require__("./src/mul.js"), mul = _require3.mul; var _require4 = __webpack_require__("./src/div.js"), div = _require4.div; var sumResult = sum(50, 50); var subResult = sub(50, 50); var mulResult = mul(50, 50); var divResult = div(50, 50); console.log({ sumResult: sumResult, subResult: subResult, mulResult: mulResult, divResult: divResult, }); })(); })(); /*! webpack! webpack! webpack! webpack! webpack! */ 4.结果分析打包之后的代码是一个 IIFE ，主要包含以下内容__webpack_modules__：key 为模块路径，value 为模块内容作为执行体的函数 __webpack_module_cache__：缓存 __webpack_require__：加载模块的方法 IIFE：这里执行 __webpack_require__ 方法并返回 module.exports babel-loader 已将代码处理为 es5 的语法 BannerPlugin 已将内容写入打包后的文件源码浅析 npm run build 执行 ./node_modules/.bin/webpack 文件 webpack-cli 负责处理执行 command 及 config 相关的配置并传入 webpack webpack 根据传入的 config 以一个或多个 js 文件为入口，递归检查每个js 模块的依赖，从而构建一个依赖关系图，然后依据该图将整个应用程序打包成一个或多个 bundle run 初始化 command 配置并注册相关的 callback 解析 command 执行 callback 加载 webpack 执行 webpack 生成 compiler runWebpack 核心代码如下： async runWebpack(options, isWatchCommand){ const callback = (error, stats) => { ... } compiler = await this.createCompiler(options, callback); } createCompiler 核心代码如下： async createCompiler(options, callback) { let config = await this.loadConfig(options); config = await this.buildConfig(config, options) compiler = this.webpack(config.options, callback) } webpack-cli 相对于 webpack 主要做了以下几件事情：解析命令行的指令解析 webpack.config.js 执行 this.webpack(config, cb) 得到 compiler 对象 webpack 该方法接收 options 和 callback 两个参数根据是否传入了 callback 决定是否执行 compiler.run() create 方法用于创建一个包含 compiler 对象的 object，核心代码如下： const create = () => { let compiler; const webpackOptions = options; compiler = createCompiler(webpackOptions) return { compiler, ...} } webpack 核心代码如下： const webpack = (options, callback) => { const create = () => { let compiler; const webpackOptions = options; compiler = createCompiler(webpackOptions) return { compiler, ...} } if (callback) { const { compiler, ... } = create(); compiler.run() } } createCompiler 对 options 进行 normalized 处理实例化 compiler 注入 compiler 到 plugin 的 apply 方法中执行相关的 hooks 在 process() 中将所有的 option 转为相应的 plugin 进行处理返回 compiler createCompiler 核心代码如下： const createCompiler = rawOptions => { const options = getNormalizedWebpackOptions(rawOptions); applyWebpackOptionsBaseDefaults(options); const compiler = new Compiler(options.context, options); if (Array.isArray(options.plugins)) { for (const plugin of options.plugins) { if (typeof plugin === "function") { plugin.call(compiler, compiler); } else { plugin.apply(compiler); } } } applyWebpackOptionsDefaults(options); compiler.hooks.environment.call(); compiler.hooks.afterEnvironment.call(); new WebpackOptionsApply().process(options, compiler); compiler.hooks.initialize.call(); return compiler; } process 核心代码如下： class WebpackOptionsApply extends OptionsApply { process(options, compiler) { // 1. 处理 options 转为 plugins // 2. 处理 entry 并在 EntryOptionPlugin 中注册 entryOption hook new EntryOptionPlugin().apply(compiler); // 3. 执行上一步注册的 entryOption hook compiler.hooks.entryOption.call(options.context, options.entry); return options; } } EntryOptionPlugin 核心代码如下： class EntryOptionPlugin { apply(compiler) { compiler.hooks.entryOption.tap("EntryOptionPlugin", (context, entry) => { EntryOptionPlugin.applyEntryOption(compiler, context, entry); return true; }); } static applyEntryOption(compiler, context, entry) { new EntryPlugin(context, entry, options).apply(compiler); } } EntryPlugin 核心代码如下： class EntryPlugin { apply(compiler) { // 1. 注册关键的 make hook callback 以便后面调用 compiler.hooks.make.tapAsync("EntryPlugin", (compilation, callback) => { compilation.addEntry(context, dep, options, err => { callback(err); }); }); } } Compiler 简单来讲，compiler 是一个包含当前运行 webpack 所有配置的对象，被实例化时会利用 tapable 初始化大量 hook 以便在 webpack 整个生命周期去注册，因此，一旦被创建便存在于 webpack 的整个生命周期中。 Compiler 核心代码如下： class Compiler { constructor(context, options) { this.hooks = Object.freeze({ // 初始化大量的 hook }) } compile(callback) { const params = this.newCompilationParams(); // 2. 创建 compilation 对象 const compilation = this.newCompilation(params); // 3. 执行 make hook callback this.hooks.make.callAsync(compilation, err => { this.hooks.finishMake.callAsync(compilation, err => { compilation.seal() }) }) } // compiler 被创建后执行 run 方法 run(callback) { const onCompiled = (err, compilation) => {} const run = () => { // 1. 执行 compile this.compile(onCompiled); }; run(); } } Compilation compilation 代表了一次单一的版本构建和资源的生成，即在编译过程中每当检测到某个文件发生变化，就会执行一次新的编译过程，从而生成编译结果。compilation 表现了当前的模块资源、编译生成资源、变化的文件、以及被跟踪依赖的状态信息，也就是说它只存在于编译阶段。 class Compilation { constructor() { this.hooks = Object.freeze({ ... }) this.entries = new Map(); // 存放所有的入口信息 this.modules = new Set(); // 存放解析后所有的模块信息 this.chunks = new Set(); // 存放 chunks 信息 this.assets = {}; // 存放生成的资源信息 } seal() {} // 对资源进行封存最终输出 assets } make 执行 make 的 callback，从 entry 开始对 module 进行 add 、build、parse factorize 会执行 resolver 去处理 module 和loader 的路径相关信息 addModule 用于生成模块间的 ModuleGraph buildModule 会通过 runLoader 执行对应的 loaders 执行 parse 方法解析 module 生成 AST 执行 processModuleDependencies 递归处理模块间的依赖并重复执行上述流程 class EntryPlugin { apply(compiler) { compiler.hooks.make.tapAsync("EntryPlugin", (compilation, callback) => { compilation.addEntry(context, dep, options, err => { callback(err); }); }) } } 执行 make 的回调开始编译，由于编译涉及大量的引用和回调，此处仅沿着执行线进行简单梳理，流程如下：以上就是处理单个模块的核心流程，拿到本次处理结果后会执行 processModuleDependencies 根据依赖对模块进行递归处理直到 parse 完所有的模块保存在 compilation 中 _doBuild(options, compilation, resolver, fs, hooks, callback) { const processResult = (err, result) => { ... const source = result[0]; const sourceMap = result.length >= 1 ? result[1] : null; ... this._source = this.createSource({...}) return callback(); } runLoaders({ ... }, (err, result) => { ... processResult(err, result.result) }) } callback(err) { const handleParseResult = result => { return handleBuildDone(); }; const source = this._source.source(); result = this.parser.parse(this._ast || source, { source, current: this, module: this, compilation: compilation, options: options }); handleParseResult(result) } seal 执行 compilation.seal() 处理 Optimization 相关配置根据处理好的 modules 生成 chunks 生成 assets 挂载到 compilation.assets 上根据 output 配置生成文件夹执行 emitFiles 输出资源到文件夹源码小结总结由于本文不是专门分析源码，而且webpack 真正的执行过程远比此处复杂得多，所以仅仅只是提取了执行过程中的核心方所做的事情进行概述讲解，使你更轻易的了解到它所做的事情；如果你有时间且有兴趣，不妨可以自己从头撸上一遍，毕竟阅读源码的过程是无聊且枯燥的，能不看就尽量别看了吧，除非你刻意要做那个很卷的人！至此，我们大概可以明确了手写 webpack 的基本思路，执行过程如下所示：手写思路 package.json "scripts": { "my-webpack": "node ./webpack/index.js", } 执行该指令模拟去加载那个可执行文件 index require("./webpack-cli") webpack-cli // 1、获取文件的配置 const webpackConfig = require("../webpack.config.js"); // 2、获取命令行配置 const getCommandOption = () => { const commandOptionList = process.argv.slice(2); const option = {}; commandOptionList.forEach((item) => { const [key, value] = item.split("="); if (key[0] !== "-" || key[1] !== "-") { console.error("options is invaild"); return false; } if (key.slice(2) && value) { option[key.slice(2)] = value; } }); return option; }; // webpack-cli 包含大量处理 command 相关的逻辑，这里我就不写了，有兴趣可自行阅读源码 // 3、合并配置 const config = { ...webpackConfig, ...commandConfig }; // 4、执行 webpack webpack(config, (err, stats) => { if (err) { console.err(error); } console.log("stats", stats); }); // 至此，webpack-cli 已经完成了自己的任务 // 关于为什么安装 webpack 也会提示一并安装 webpack-cli ? 我们可以只安装 webpack 吗？ // 当然可以。因为 webpack 依赖 webpack-cli 会处理配置相关的功能。 // 如果我们可以自己解析并生成 config 交给 webpack 处理，那就只安装 webpack 就可以了 // 毕竟 vite 之前的 vue 和 react ，二者也都没有安装过 webpack-cli webpack const Compiler = require("./Compiler") // 简单处理下 entry 兼容 string 和 object 的形式传入, 数组自己可以尝试处理下哈 const getNormalizedEntryStatic = (entry) => { if (typeof entry === "string") { return { main: entry, }; } if (Object.prototype.toString.call(entry) === "[object Object]") { return { ...entry }; } }; const createCompiler = (options) => { options.entry = getNormalizedEntryStatic(options.entry); const compiler = new Compiler(options); // 将 compiler 传入 plugins 中 if (Array.isArray(options.plugins)) { for (const plugin of options.plugins) { if (typeof plugin === "function") { plugin.call(compiler, compiler); } else { plugin.apply(compiler); } } } return compiler; }; const webpack = (config, callback) => { // 1、创建 compiler 对象 const compiler = createCompiler(config); if (callback) { // 2、调用 run 方法之前我们初始化好的 run hook compiler.hooks.run.call(); // 3、执行 compiler 的 run 方法 compiler.run((err, stats) => { if (err) { console.error(err); } console.log(stats); }); } }; module.exports = webpack Compiler const { SyncHook } = require("tapable"); const Compilation = require("./Compilation") class Compiler { constructor(options) { // 1、简单初始化两个 hook 意思一下 this.hooks = { run: new SyncHook(), done: new SyncHook(), }; // 2、保存一个 context，这里跳过用户配置简单处理 this.context = process.cwd(); // 3、保存一份 options this.options = options; } run() { // 4、创建 Compilation 这里我们把这个 compiler 直接传过去 const compilation = new Compilation(this); // 5、从 entry 开始处理 compilation.addEntry(); } } module.exports = Compiler Compilation const fs = require("fs"); const path = require("path"); const parse = require("./parse") const runLoaders = require("./runLoaders") const codeGeneration = require("./codeGeneration") class Compilation { constructor(compiler) { this.compiler = compiler; this.entries = new Set(); // 入口模块 this.modules = new Set(); // 依赖模块 this.chunks = new Set(); // chunks this.sourceCode = ""; // 源码 this.assets = {}; // 即将打包的资源 } // 读取模块 => 用 loader 处理模块 => 解析模块 build(moduleName, modulePath) { const sourceCode = fs.readFileSync(modulePath, "utf-8"); runLoaders(this, modulePath, sourceCode); return parse(this, moduleName, modulePath); } addEntry() { // 1、从入口开始依次处理 const { context, options } = this.compiler; for (const entryName in options.entry) { if (Object.hasOwnProperty.call(options.entry, entryName)) { const entryPath = options.entry[entryName]; // 2、build 处理 const buildCompletedModule = this.build( entryName, path.resolve(context, entryPath) ); // 3、处理完成添加到 entries this.entries.add(buildCompletedModule); // 4、对资源进行打包输出 this.seal(entryName, buildCompletedModule); } } } addChunk(entryName, entryModule, callback) { const chunk = { name: entryName, entryModule: entryModule, modules: Array.from(this.modules).filter((i) => i.name.includes(entryName) ), }; this.chunks.add(chunk); callback(); } seal(entryName, entryModule) { this.addChunk(entryName, entryModule, () => { this.emitAsset(); }); } emitAsset() { const output = this.compiler.options.output; this.chunks.forEach((chunk) => { const outputFileName = output.filename.replace("[name]", chunk.name); this.assets[outputFileName] = codeGeneration(chunk); }); if (!fs.existsSync(output.path)) { fs.mkdirSync(output.path); } Object.keys(this.assets).forEach((fileName) => { const filePath = path.join(output.path, fileName); fs.writeFileSync(filePath, this.assets[fileName]); }); this.compiler.hooks.done.call(); } } module.exports = Compilation runLoaders // 遍历加载所有的 loader 作用在源码模块上 const runLoaders = (compilation, modulePath, sourceCode) => { const usedLoaders = []; const rules = compilation.compiler.options.module.rules; for (const rule of rules) { if (rule.test.test(modulePath)) { if (rule.loader) { usedLoaders.push(rule.loader); } if (rule.use) { usedLoaders.push(...rule.use); } } } // 倒序处理 for (let i = usedLoaders.length - 1; i >= 0; i--) { compilation.sourceCode = require(usedLoaders[i])(sourceCode); } }; module.exports = runLoaders parse const path = require("path"); const parser = require("@babel/parser"); const { genAbsPath, genModuleId } = require("./utils"); const traverse = require("@babel/traverse").default; const generator = require("@babel/generator").default; const types = require("@babel/types"); const parse = (compilation, moduleName, modulePath) => { // 1. 创建模块 const module = { id: genModuleId(compilation.compiler.context, modulePath), name: [moduleName], __source: "", dependencies: new Set(), }; // 2. 生成 ast const ast = parser.parse(compilation.sourceCode, { sourceType: "module", }); // 3. 对源码进行转换这里仅针对 require 引入 traverse(ast, { CallExpression: ({ node }) => { if (node.callee.name === "require") { const nodeName = node.arguments[0].value; const nodeDirName = path.posix.dirname(modulePath); const nodeAbsPath = genAbsPath( path.posix.join(nodeDirName, nodeName), compilation.compiler.options.resolve.extensions, nodeName, nodeDirName ); const moduleId = genModuleId(compilation.compiler.context, nodeAbsPath); node.callee = types.identifier("__webpack_require__"); node.arguments = [types.stringLiteral(moduleId)]; // 判断模块是否重复引入处理 const loadedModules = Array.from(compilation.modules).map((i) => i.id); if (!loadedModules.includes(moduleId)) { module.dependencies.add(moduleId); } else { compilation.modules.forEach((i) => { if (i.id === moduleId) { i.name.push(nodeName); } }); } } }, }); // 4. 代码生成 const { code } = generator(ast); // 5. 在 module 对象上挂载一份生成好的源码 module.__source = code; // 6. 处理模块依赖 module.dependencies.forEach((dep) => { const depModule = compilation.build(moduleName, dep); compilation.modules.add(depModule); }); return module; }; module.exports = parse; utils const fs = require("fs"); const path = require("path"); const genAbsPath = (modulePath, extensions, nodeName, nodeDirName) => { if (fs.existsSync(modulePath)) return modulePath; for (const extension of extensions) { if (fs.existsSync(modulePath + extension)) { return modulePath + extension; } } }; const genModuleId = (context, modulePath) => { return `./${path.posix.relative(context, modulePath)}`; }; module.exports = { genAbsPath, genModuleId, }; codeGeneration // 简单模拟下 const codeGeneration = (chunk) => { const { entryModule, modules } = chunk; return ` (() => { var __webpack_modules__ = { ${modules .map((module) => { return ` '${module.id}': (module) => { ${module.__source} } `; }) .join(",")} }; var __webpack_module_cache__ = {}; function __webpack_require__(moduleId) { var cachedModule = __webpack_module_cache__[moduleId]; if (cachedModule !== undefined) { return cachedModule.exports; } var module = (__webpack_module_cache__[moduleId] = { exports: {}, }); __webpack_modules__[moduleId](module, module.exports, __webpack_require__); return module.exports; } (() => { ${entryModule.__source} })(); })(); `; }; module.exports = codeGeneration;

life.caoabout 4 years

浅谈浏览器的剪切板 API 及其实践

浅谈浏览器的剪切板 API 及其实践前言同事在使用公司后台系统时，常常会把某块内容截图分享到工作群，用于反馈或咨询问题。作为一名熟练掌握 Ctrl C+V 的前端开发，我思考能否实现一个功能，可以一键点击将某块的页面内容准确又快捷地复制到粘贴板，再粘贴到其它地方。演示：浏览器中的剪切板：Clipboard API Clipboard 接口实现了 Clipboard API，如果用户授予了相应的权限，其就能提供系统剪贴板的读写访问能力。在 Web 应用程序中，Clipboard API 可用于实现剪切、复制和粘贴功能。Clipboard 是浏览器新提供的剪贴板操作方法，用于取代安全隐患比较大的 document.execCommand。 Clipboard API 目前属于比较新的 API，浏览器仍在逐步实现它，兼容性如下：需要注意： navigator.clipboard 需要在安全域 https 下使用读写操作需要用户授权，权限已添加到 Permissions API 中页面处于活动选项卡才能调用 Clipboard 的所有操作都是异步的，返回 Promise 对象，支持将任意内容放入剪贴板，这就给将图片放入剪贴板提供能实现的可能，可通过全局属性调用 Clipboard API： navigator.clipboard API Clipboard 提供了两个写入剪贴板的方法，分别是： writeText() navigator.clipboard.writeText() 方法可以写入字符串到操作系统的剪切板。参数要写入的 DOMString。返回值返回一个 Promise 对象，数据写入成功则执行 resolve，否则执行 reject。 <button onclick="copyCurrentTime()">拷贝当前时间</button> <script> async function copyCurrentTime() { await navigator.clipboard.writeText(new Date()); console.log("页面地址已经被拷贝到剪贴板中"); } </script> write() navigator.clipboard.write() 方法支持写入任意数据（文本数据、二进制数据）到剪贴板。参数一个包含构造函数 ClipboardItem() 生成的 ClipboardItem 实例对象数组，这个构造函数接受一个对象作为参数，该对象的 key 是数据的 MIME 类型，value 是 Blob 类型对象数据。返回值返回一个 Promise 对象，数据写入成功则执行 resolve，否则执行 reject。下面例子演示复制图片到剪贴板，根据图片链接获取到资源，转成 Blob 二进制对象，然后使用该对象来构造 ClipboardItem 对象，最后调用 write() 异步写入剪贴板。代码： async function writeClipImg() { const imgURL = 'https://webapi.XXX.com/assets/default.png'; const data = await fetch(imgURL); const blob = await data.blob(); await navigator.clipboard.write([ new ClipboardItem({ [blob.type]: blob, }), ]); } 上面代码展示的是将图片资源写入剪贴板的过程，那么该如何将为文档流中的 DOM 元素写入剪贴板呢？同样的思路，能否把 DOM 转换成图片？生成 DOM 图片社区里比较流行的 npm 库是 html2canvas 和 dom-to-image，他们都是将页面上显示的 DOM 元素，经过解析画在 canvas 上，最后在转换为 Image 或 SVG 格式，以下操作思路主要参考 dom-to-image。生成 DOM 图片的核心思想是利用了 SVG 的 **[<foreignObject>](https://developer.mozilla.org/zh-CN/docs/Web/SVG/Element/foreignObject)** 元素，该元素可以在 SVG 内部渲染 HTML 标签，那么拥有了包含目标 DOM 的 SVG 后，我们就能很轻易的生产图片。大致流程如下：节点克隆节点使用 Node.``cloneNode``()，但由于需要对每个节点进行「特殊处理」(样式和资源等)，使用 cloneNode(deep = true)无法满足需求，所以需要手动遍历克隆。克隆节点如果 node 为HTMLCanvasElement，则转成 DataURL 并返回 Image 对象。 /** * @param {*} original 原始节点 * @returns 克隆节点 */ function copyNode(original) { if (original instanceof HTMLCanvasElement) { return new Promise((resolve, reject) => { const image = new Image(); image.src = original.toDataURL(); image.onload = resolve(image); image.onerror = reject; }); } return original.cloneNode(false); } 克隆子节点还要克隆所有子节点 childNodes。 /** * @param {*} original 原始节点 * @param {*} clone copyNode()返回的克隆节点 * @returns 已克隆子节点的克隆节点 */ function copyChildren(original, clone) { // 获取子节点 const children = original.childNodes; if (children.length === 0) return Promise.resolve(clone); return cloneChildrenInOrder(clone, Array.from(children)) .then(clone); /** * @param {*} parent 父节点 * @param {*} children 克隆的子节点 */ function cloneChildrenInOrder(parent, children) { const done = Promise.resolve(); // 遍历子元素，逐一克隆并复制样式添加到父节点当中 children.forEach(function (child) { done = done .then(() => cloneNode(child)) .then((childClone) => { if (childClone) parent.appendChild(childClone); }); }); return done; } } 结合以上克隆一个节点 /** * @param {*} node 目标节点 * @returns 手动克隆后的节点 */ function cloneNode(node) { return Promise.resolve(node) .then(copyNode) .then((clone) => copyChildren(node, clone)) } 样式上面提到使用 Node.cloneNode() 会有样式丢失的情况，因此需要对样式重新做赋值处理。克隆样式转换的目标是包含指定 DOM 的 SVG，那么所有导入的外部样式将不生效，所以克隆的 className 也无法生效，就需要利用 getComputedStyle 获取原节点的样式属性和值，再遍历样式属性通过setProperty 重新赋值到克隆节点，其中CSS属性优先级则通过 getPropertyPriority 获取，将样式转成内联样式来解决此问题。 /** * @param {*} original 原始节点 * @param {*} clone 克隆节点 */ function cloneStyle(original, clone) { const source = window.getComputedStyle(original); Array.from(source).forEach((name) => { clone.style.setProperty( name, source.getPropertyValue(name), source.getPropertyPriority(name), ); }); } 处理伪元素对于伪元素 :before、:after 等，cloneNode() 无法克隆，所以需要提取出样式，作为style 添加到节点当中。[window.getComputedStyle()](https://developer.mozilla.org/zh-CN/docs/Web/API/Window/getComputedStyle) API第二个参数支持指定一个伪元素字符串，可以查询到该伪元素的样式信息。 function clonePseudoElements() { [":before", ":after"].forEach((pseudo) => { // 查询指定伪元素 const style = window.getComputedStyle(original, pseudo); const content = style.getPropertyValue("content"); if (content === "" || content === "none") return; // 生成伪元素类名 const className = `xxx`; // 添加伪元素类 clone.className = `${clone.className} ${className}`; // 拼接样式 const cssText = `${Array.from(style) .map((name) => { return `${name}: ${style.getPropertyValue(name)}`; }).join("; ")};` const styleElement = document.createElement("style"); // 样式内容嵌入style styleElement.innerHTML = `.${className}:${pseudo}{ ${cssText} }`; clone.appendChild(styleElement); }); } 图片链接 Img 标签链接对于标签，需要将图片链接src转成dataURL形式。 <img src="https://static.xxx.cn/image/6ce5...262f8.svg"> 需要转成： <img src="data:image/svg+xml;base64,PD94b...XXXXX"> 通过图片链接获取资源并处理成 DataURL 返回： function getImgDataURL(url) { return new Promise((resolve) => { // 发起XMLHttpRequest const request = new XMLHttpRequest(); request.onreadystatechange = () => { if (request.readyState !== 4) return; if (request.status !== 200) resolve('') const encoder = new FileReader(); // 将blob类型转成DataURL encoder.readAsDataURL(request.response); encoder.onloadend = function () { resolve(encoder.result); }; }; // blob类型请求 request.responseType = 'blob'; request.open('GET', url, true); request.send(); }); } 替换 Img 的 src： function inlineImage(Image) { // 如果src是DataURL形式则不处理 if (Image.src.search(/^(data:)/) !== -1) return Promise.resolve(); return Promise.resolve(Image.src) .then(getImgDataURL) .then((dataUrl) => { return new Promise((resolve, reject) => { Image.src = dataUrl; Image.onload = resolve; Image.onerror = reject; }); }); } background 样式链接同样，对于样式使用了 background: url() 来设置背景图片的节点，也要处理： background: url("https://webapi.XXX.com/assets/default.png") 0% 0% / cover repeat scroll padding-box border-box rgba(0, 0, 0, 0); 需要转成 DataURL： background: url("data:image/png;base64,iVBOR...CYII=") 0% 0% / cover repeat scroll padding-box border-box rgba(0, 0, 0, 0); 需要注意的是节点的 background 属性可能存在多个 url()，所以通过 [RegExp.prototype.exec()](https://developer.mozilla.org/zh-CN/docs/Web/JavaScript/Reference/Global_Objects/RegExp/exec) 正则 API 找出出所有图片链接： function parseBackground(node) { const background = node.style.getPropertyValue('background'); // 正则规则 const URL_REGEX = /url$['"]?([^'"]+?)['"]?$/g; const result = []; let match; while ((match = URL_REGEX.exec(background)) !== null) { result.push(match[1]); } } 和上文 Img 标签链接处理方式类似，遍历处理 background 属性的 url 链接： function inlineUrl(node) { const background = node.style.getPropertyValue('background'); return Promise.resolve(background) .then(() => { const urls = parseBackground(node) let done = Promise.resolve(background); urls.forEach((url) => { done = done.then((background) => { return inline(background, url); }); }); return done; }); } function inline(background, url) { return Promise.resolve(url) .then(getImgDataURL) .then((dataUrl) => { // dataUrl替换原url链接 const res = background.replace(url, dataUrl); return res; }); } 最后重新赋值节点 background： function inlineBackground(node) { reurn inlineUrl(node) .then((inlined) => { node.style.setProperty( 'background', inlined, node.style.getPropertyPriority('background'), ); }) .then(() => node); } 水印后台系统页面生成的 DOM 图片可能会涉及到安全等级的数据，基于公司信息安全考虑，图片需要添加水印。使用 canvas 绘制水印内容，然后利用 canvas.toDataURL() 生成水印图片，最后向目标节点添加包含水印背景的伪元素 style。 function createWaterMark(node, config) { const {content, alpha, fontSize, rotate} = config return new Promise((resolve) => { const canvas = document.createElement("canvas"); canvas.width = 250; canvas.height = 100; const ctx = canvas.getContext("2d"); if (ctx) { ctx.font = `${fontSize}px PingFang SC, sans-serif`; ctx.fillStyle = `rgba(0, 0, 0, ${alpha})`; ctx.textAlign = "left"; ctx.rotate((Number(rotate) * Math.PI) / 180); ctx.fillText(content, 50, 50); } // canvas生成水印图片dataURL const backgroundUrl = canvas.toDataURL(); // 定义水印类名 const className = `waterMarker${new Date().getTime()}`; // 节点添加类名 node.className = `${node.className} ${className}`; const style = document.createElement("style"); style.innerHTML = `.${className}::after{ ... background-image: url(${backgroundUrl}); }`; node.appendChild(style); resolve(node); }); } 序列化与绘制克隆节点序列化为 XML 到目前为止，已经拿到了结构被深度复制且样式内联化处理的克隆节点。目标是使用元素嵌入目标节点并使用 SVG 渲染出来，所以使用 XMLSerializer.serializeToString() 将节点序列化成一串 XML 字符串。 function createSvgDataUrl(node, width, height) { return Promise.resolve(node) .then((node) => { // 设置xmlns命名空间属性与SVG区分开 node.setAttribute('xmlns', 'http://www.w3.org/1999/xhtml'); return new XMLSerializer().serializeToString(node); }) .then((xhtml) => { // 嵌入foreignObject return `<foreignObject x="0" y="0" width="100%" height="100%">${xhtml}</foreignObject>`; }) .then((foreignObject) => { return `<svg xmlns="http://www.w3.org/2000/svg" width="${width}" height="${height}">${foreignObject}</svg>`; }) .then((svg) => { return `data:image/svg+xml;charset=utf-8,${svg}`; }); } 嵌入节点 SVG 的 DataURL 数据： canvas 绘制剩下的工作就交给 canvas 绘制，再转成 Blob 二进制，最后 Clipboard 写入剪贴板。 function drawDomImage(node) { return getSvgDataUrl(node).then((dataUrl) => { return new Promise((resolve, reject) => { const img = new Image(); img.src = dataUrl; img.onload = function () { const canvas = document.createElement('canvas'); canvas.width = getWidth(node); canvas.height = getHeight(node); canvas.getContext('2d').drawImage(img, 0, 0); canvas.toBlob(resolve); }; img.onerror = reject; }); }); } drawDomImage(target) .then(blob) => { navigator.clipboard.write([ new ClipboardItem({ [blob.type]: blob, }), ]) .then(() => alert("复制成功")), .catch(() => alert("复制失败")); }) .catch((err) => console.log(err)); 总结本文通过分析如何将 DOM 复制到剪贴板的过程，介绍了 Clipboard API 的特性以及 DOM 生成图片的处理思路，并帮助大家熟悉克隆 DOM 元素和样式的方法。初衷是实现一键截屏模块功能，此功能看上去似乎没有比调用截图工具提升多少优化，但生成 DOM 图片的操作也可以应用在其它业务场景，例如：弹窗图片、制作海报、制作名片、二维码截屏等，希望本文对大家有所帮助。参考资料 Clipboard API - MDN foreignObject - MDN RegExp.prototype.exec() | MDN

life.caoabout 4 years

怎样编写一条自定义 eslint 规则

怎样编写一条自定义 eslint 规则背景最近在使用 umi 的过程中发现一个问题，VSCode 自动导入 umi 模块时经常会从 .umi 目录导入，例如: import { useRequest } from '@/.umi/plugin-request/request'; 这种情况导入后在开发环境可以正常使用，但是打包发布之后则会因为没有.umi目录而报错。那有没有办法在开发阶段就发现并规避这个问题呢？如果要在开发阶段发现问题，首先就考虑 eslint 是否可以满足我们的需求，当使用非法路径导入时，可以通过 eslint 给一个错误提醒，如果可以直接帮我们修复那就更好了。查阅 eslint 插件文档后发现有这样一条规则: 'import/no-internal-modules': ['error', { forbid: ['**/.umi/**'] }] 这条规则会在匹配到禁用路径时报错，但是并没有提供修复功能。如果只是禁用路径的话这条规则已经可以勉强满足我们的需求了，但是这个时候想到另外一个类似的需求场景。我们在项目中有时会重写一些外部模块，重写后我们期望所有的地方都统一使用重写后的模块，如果可以自动替换某个模块的导入路径，那么就可以统一这个模块的导入路径了。明确需求首先确定一下我们要实现的效果：禁用 @/.umi 目录，并把相关目录自动转为 umi 禁用某个路径下的某个模块，例如我们重写了 react-router 的 Link 和 useHistory 模块，所以 import { useModel, Link } from 'umi'; 需要自动替换为 import { useModel, useHistory } from '``@/utils/router``'; 最终的在.eslitrc文件中的配置如下：实现需求初始化项目 eslint 为我们提供了一套脚手架可以快速创建插件：全局安装 yo 和 generator-eslint yarn global add yo generator-eslint 新建一个空文件夹并执行 yo eslint:plugin 执行 yo eslint:rule 新建一条规则使用脚手架新建一条规则后，会生成三个文件，分别对应文档、代码和测试：编写规则文档文档可以参考其他的 eslint 插件，按照建议的格式编写即可例如：https://github.com/import-js/eslint-plugin-import/blob/main/docs/rules/no-absolute-path.md 编写测试用例测试分为 valid 和 invalid 两部分，valid 是符合规则的代码，invalid 是不符合规则的代码，在 invalid 中写入所有我们需要处理的情况： const rule = require('../../../lib/rules/no-internal-modules'), RuleTester = require('eslint').RuleTester; const ruleTester = new RuleTester({ parserOptions: { ecmaVersion: 2020, sourceType: 'module' } }); const options = [ { target: '**/.umi/**', replace: 'umi' }, { target: 'umi', replace: '@/utils/router', modules: ['Link', 'useHistory'] } ]; ruleTester.run('no-internal-modules', rule, { valid: [ { code: "import { useRequest } from 'umi'", options }, { code: "import { useModel } from 'umi'", options }, { code: "import { useRequest, useModel } from 'umi'", options } ], invalid: [ { code: "import { useRequest } from '@/.umi/request-plugin/request';", errors: [{ messageId: 'replace-path', data: { target: '@/.umi/request-plugin/request', replace: 'umi' } }], options, output: "import { useRequest } from 'umi';" }, { code: "import { Link, useModel } from 'umi';", errors: [{ messageId: 'replace-module', data: { name: 'Link', replace: '@/utils/router' } }], options, output: "import { useModel } from 'umi';\nimport { Link } from '@/utils/router';" }, ] }); 编写代码代码主要分为 meta 对象和 create 方法两个部分。 meta 对象主要是规则相关的配置，详情可查阅官方文档 create 方法接收一个 context 参数，context 对象有一些属性和方法可以使用，我们这里用到的主要有两个： context.options: eslint 规则配置传入的参数 context.report: 检测到错误之后报告的方法 create 方法返回一个对象 create (function) 返回一个对象，其中包含了 ESLint 在遍历 JavaScript 代码的抽象语法树 AST (ESTree 定义的 AST) 时，用来访问节点的方法。如果一个 key 是个节点类型或 selector，在向下遍历树时，ESLint 调用 visitor 函数如果一个 key 是个节点类型或 selector，并带有 :exit，在向上遍历树时，ESLint 调用 visitor 函数如果一个 key 是个事件名字，ESLint 为代码路径分析调用 handler 函数一个规则可以使用当前节点和它周围的树，报告或修复问题。借助 AST Explorer 工具把我们的目标代码转换一下：通过观察 AST 可以发现，我们需要处理的节点类型为 ImportDeclaration，在 create 方法中返回 key 为 ImportDeclaration 的 selector 即可捕获到相关代码： create(context) { return { ImportDeclaration: (node) => { // 拿到节点后，遍历在规则内配置的参数 context.options.forEach((option) => { // 通过 minimatch 把规则转换成正则表达式 const regexp = minimatch.makeRe(option.target); if (!regexp.test(node.source.value)) { return; } // 判断如果配置中包含 modules 参数，即为模块替换，否则为导入路径替换 if (option.modules) { reportModuleList(node, option); return; } reportPath(node, option); }); } }; } 在匹配到 ImportDeclaration 节点后，需要遍历我们配置的规则，判断规则中是否存在 modules 参数，当存在 modules 参数时，需要对 modules 内的模块的导入路径进行替换。通过 context.report 可以上报错误，通过 fix 方法修复错误--先删除本次导入中对应的模块，再插入一行从正确路径导入此模块的代码： const reportModule = (spec, node, option, isLast) => { const moduleName = spec.imported.name == spec.local.name ? spec.imported.name : `${spec.imported.name} as ${spec.local.name}`; // 通过 context.report 即可上报错误 context.report({ node: spec.imported, messageId: 'replace-module', data: { name: moduleName, replace: option.replace }, // 通过 fix 方法修复错误，先删除本次导入中对应的模块，再插入一行从正确路径导入本模块的代码 fix: function (fixer) { return [ fixer.removeRange([spec.range[0], isLast ? spec.range[1] : spec.range[1] + 1]), fixer.insertTextAfter(node, `\nimport { ${moduleName} } from '${option.replace}';`) ]; } }); }; const reportModuleList = (node, option) => { node.specifiers.forEach((spec, index) => { if (spec.type !== 'ImportSpecifier') { return; } // 如果导入模块名称符合配置的规则，就替换此模块的导入路径 if (option.modules.includes(spec.imported.name)) { reportModule(spec, node, option, index === node.specifiers.length - 1); } }); }; 不存在 modules 参数时，直接替换导入路径即可： const reportPath = (node, option) => { context.report({ node: node.source, messageId: 'replace-path', data: { target: node.source.value, replace: option.replace }, fix: function (fixer) { return fixer.replaceText(node.source, `'${option.replace}'`); } }); }; 代码写完并执行测试通过后，就可以发布到 npm 仓库了配置和使用首先安装我们发布的 npm 包 yarn add eslint-plugin-import-path-plus --dev 把新安装的插件添加到 eslint 配置的 plugins 里面： { "plugins": [ "import-path-plus" ] } 把规则配置到 eslint 配置的 rules： { "rules": { 'import-path-plus/no-internal-modules': [ 'warn', { target: '**/.umi/**', replace: 'umi' }, { target: 'umi', replace: '@/utils/router', modules: ['Link', 'useHistory'] } ] } } 现在就可以看到效果了：点击 Quick Fix 或者执行 eslint --fix ，就可以自动修复了。总结本文通过发现问题、分析问题、确定需求和实现需求的路径，最后通过编写 eslint 规则，解决了我们最初的问题。我们在项目中有时会重写一些外部模块，重写后我们期望所有的地方都统一使用重写后的模块，此时即可使用此规则，自动把相关模块的导入替换成内部路径。引用链接 https://eslint.bootcss.com/docs/developer-guide/working-with-rules

107

life.caoabout 4 years

从React DevTools中发掘 ReactDOM 中的一些隐藏特性

从React DevTools中发掘 ReactDOM 中的一些隐藏特性有过 React 经验的开发者可能都使用过 React DevTools。DevTools 提供了丰富的能力：展示组件树，组件的 props 与组件中 hook 的值。React Devtools 是如何检测当前网页是否使用 React 以及是如何获取组件相关的众多数据呢？ React Devtools 的原理打开 ReactDOM 代码时，用 devtools 为关键字搜索，你会发现许多与 React Devtools 相关的代码。 function injectInternals(internals) { if (typeof __REACT_DEVTOOLS_GLOBAL_HOOK__ === 'undefined') { // No DevTools return false; } var hook = __REACT_DEVTOOLS_GLOBAL_HOOK__; try { rendererID = hook.inject(internals); // We have successfully injected, so now it is safe to set up hooks. injectedHook = hook; } catch (err) { // ... } // DevTools exists } 在浏览器控制台输入 __REACT_DEVTOOLS_GLOBAL_HOOK__ 详细看一下这个对象。这个对象十分复杂，以下的几个方法倒是很值得关注。 onCommitFiberRoot onCommitFiberUnmount onPostCommitFiberRoot 渲染阶段从方法名称来看，上面这几个肯定是与 ReactDOM 的渲染密切关联了。ReactDOM 在特定的阶段会调用这些的方法，比如：onCommitFiberRoot。 function onCommitRoot(root, priorityLevel) { if (injectedHook && typeof injectedHook.onCommitFiberRoot === 'function') { try { // ... injectedHook.onCommitFiberRoot(rendererID, root, priorityLevel, didError); } catch (err) {} } } 正是借助 __REACT_DEVTOOLS_GLOBAL_HOOK__，React Devtools 便与 ReactDOM 建立起了联系，从而拥有获取组件众多信息的能力。 FiberRoot/FiberNode 在新的 React 架构下，会先把 Virtual DOM 转成 FiberNode，然后再渲染 FiberNode。onCommitFiberRoot 等这些方法中的传递的数据正是 FiberNode。FiberNode 的结构是比较复杂的，可以简化为如下的结构： interface ReactFiberRootNode { current: ReactFiberNode; } interface ReactFiberNode { tag: number; stateNode: null | HTMLElement; // dom 节点 memoizedProps?: Record<string, any>; // props memoizedState: ClassComponentState | HookLinkedQueue | null; // hooks child?: ReactFiberNode; sibling?: ReactFiberNode; return: ReactFiberNode; // parent // ... } 从上面的结构可以看出，FiberNode 包含了非常多与组件相关的信息。stateNode 为组件对应真实的 DOM 节点，memoizedProps 为组件的 props。当组件为函数式组件时，tag 为 0，memoizedState 保存了组件中的 hooks 信息。当组件为类组件是，tag 为 1，memoizedState 则是组件的 state。如下图所示，FiberNode 节点形成一个链表结构。只要能获取组件对应的 FiberNode，我们便可以做到在运行期间以无侵入的方法获取组件的众多信息。比如：通过 FiberNode 进行遍历，实现 findNativeNodesForFiber 方法，用以查到找其对应的真实 DOM 节点。 function findNativeNodesForFiber(node?: ReactFiberNode) { // ... // 先遍历 child const { child } = node; collectStateNode(); // 再遍历所有的 sibling let current = child?.sibling; while (current) { collectStateNode(); current = current.sibling; } // ... } React Devtools 中审查元素功能正是基于类似的原理去实现。 memoizedState 与 React Hooks 上文中提到当组件为函数式组件时，memoizedState 保存了 React Hooks 相关的信息。与 FiberNode 类似，React Hooks 也形成一个链表。 export interface HookLinkedQueue { memoizedState: any; // 渲染时的值 next: HookLinkedQueue | null; // ... } React Hook 将其数据都保存在 memoizedState 上。比如对于 useRef 来说，ref.current 值就是 memoizedState。类似的，可以实现 inspectSomeHooksOfFiber 来获取组件内使用特定 hook 中保存的值。 function inspectRefHooksOfFiber(node: ReactFiberNode) { let current: HookLinkedQueue | null = node.memoizedState; while (current) { retrieveValue(current); current = current.next; } } 实践：突破 useDebugValue 的限制 useDebugValue 是 React 内置的一个 hook，用以在 React Devtools 中显示自定义 hook 的标签。它的限制是只能在 hook 中使用。借助前文介绍的知识点，我们可以实现一个增加版的 useDebugValue，你可以像普通的 hook 一样来使用它，没有其他限制。 useDebugValueAnywhere 的实现为了与标准的 useDebugValue 区分，将之命名为useDebugValueAnywhere。其实现比较简单，name 表明数据的名称，用一个特殊的 ref 对象来存储 debug 相关的数据。 export function useDebugValueAnywhere(name: string, data: any) { const ref = useRef({ [DebugHookKey]: { name, data, }, }); // ... } 特定的 devtools 参考 React Devtools 的逻辑，在 __REACT_DEVTOOLS_GLOBAL_HOOK__ 中注入我们的 onCommitFiberRoot 方法，从而确保 ReactDOM 每次渲染时，能获取最新的 FiberNode。 currentHook.onCommitFiberRoot = function (...args) { handleCommitFiberRoot(...args); // 注入 oldOnCommitFiberRoot.apply(this, args); }; 接下来便是对 FiberNode 进行遍历。在遍历的过程中，检查每个 FiberNode 中 memoizedState 链表，检测组件的 hooks 中是否用到了 useDebugValueAnywhere。如果存在，就将值 FiberNode 与 hook 中的值收集起来。 { visitFiberNode(node?: ReactFiberNode) { if (!node) return; this.inspectFiber(node); this.visitFiberNode(node.child); let { sibling } = node; while (sibling) { this.visitFiberNode(sibling); sibling = sibling.sibling; } } } 剩下的工作就是考虑以何种形式去展示收集到的 debug 信息。在 PC 端可以直接输出数据到控制台；在移动端 vConsole 使用较多，那么就可以基于 vConsole 开发一个插件，实现一个极简版的 React Devtools，专门用以展示这些信息。总结本文通过剖析了 React Devtools 的原理，介绍隐藏在 ReactDOM 中的一些特性，并带领大家熟悉了一下 React Fiber 架构。基于上述原理，可以开发一个增加版的 useDebugValue。由于本文介绍的特性并非公开的 API，没有兼容性。当 React/ReactDOM 版本升级时，可能还需要再做适配，因此只适合用来开发 Devtools 之类的工具，不推荐业务开发使用。

life.caoabout 4 years

代码重构之理论和实践

代码重构之理论和实践主要改造点重构的每个步骤都很简单，甚至显得有些过于简单：只需要把某个字段从一个类移到另一个类，把某些代码从一个函数拉出来构成另一个函数，或是在继承体系中把某些代码推上推下就行了。但是，聚沙成塔，这些小小的修改累积起来就可以根本改善设计质量。这和一般常见的“软件会慢慢腐烂”的观点恰恰相反。——《重构：改善既有代码的设计》本文结合《重构：改善既有代码的设计》中的观点，从本次重构的项目出发，分别从神秘代码、过长函数、全局变量、响应拦截和链路过长五个方面来讲述。神秘代码代码必须明确说出你的意图，而且必须富有表达力。这样可以让代码更易于被别人阅读和理解。代码不让人迷惑，也就减少了发生潜在错误的可能。一言以蔽之，代码应意图清晰，表达明确。——《高效程序员的45个习惯：敏捷开发修炼之道》这里的神秘代码指的就是魔数（magic number），是指代码中出现的没有说明用途的数字。根据编程中的 PIE （Program Intently and Expressively）原则，代码必须明确地表达自己的意图。很明显，魔数便是 PIE 原则的反面例子，这些谜一样的存在数字会给编程人员造成很大的阅读成本，进一步会导致程序出错，再而增加维护成本，而解决魔数的方式其实很简单。所以把代码中魔数处理掉，是一件收益远大于成本的事情，值得我们去做。下面我们来看本次重构中出现的魔数： const unPassList = [4, 5, 6, 7, 9]; const needTaxiUploadList = [2, 18, 19]; 看到上面的代码我猜你肯定会很疑惑，这些数字到底是什么意思？我们先了解下背景，首先司机注册流程是分步骤的，司机可以在注册流程中任意一步退出然后再登录，所以在代码设计的时候便会不同的数字来代表不同的注册步骤，如“注册中”、“驳回重传”、“补充资料”等等，这是出现魔数的第一种情况。其次，司机注册需要上传各种证件，如“身份证”、“驾驶证”等等，这样代码中又需要使用不同的数字来代表这些证件。这是第二种情况。当然不要忘了，一般接口返回的错误码也是数字，这可以说是第三种情况。最后这样多种情况结合在一起，便出现了一个数字有多个含义的情况。比如数字“4”，可能代表着“已经填写了身份信息”这一注册状态，也可以是“身份证”这一证件类型，还可以是“人脸验证通过”这一状态。类似以上的代码在这次改造前的代码中随处可见，大多都是比较简单的语句，但是个中含义却让人捉摸不透，即使能明白数字的含义也很难理清。基于这些原因，这些数字有必要统一收口到枚举中来管理，如 export enum RegisterStatusEnum { PASS = 1, // 申请通过 PHONE_PASS = 2, // 手机认证通过 // ... } 使用时直接从枚举中读取 const unPassList = [ RegisterStatusEnum.FILLED_ID_CARD, RegisterStatusEnum.DESTORY, // ... ]; 这样处理的好处是使代码更加简单明了，增加可读性，不至于让人感到困惑，其次也便于代码的管理，后续如果枚举值有变化，只需在枚举中修改一处即可，不用每个数字都去改，增加开发效率。过长函数我们应该遵循这样一条原则：每当感觉需要以注释来说明点什么的时候，我们就把需要说明的东西写进一个独立函数中，并以其用途（而非实现手法）命名。我们可以对一组甚至短短一行代码做这件事。哪怕替换后的函数调用动作比函数自身还长，只要函数名称能够解释其用途，我们也该毫不犹豫地那么做。关键不在于函数的长度，而在于函数“做什么”和“如何做”之间的语义距离。——《重构：改善既有代码的设计》这里过长函数指的就是在一个函数体内堆积了大量的代码，而这样的代码往往都是可以拆成一个个小函数的。从最浅显的角度来看，如果一个函数的长度超出了电脑屏幕的高度，我们就需要不断地上下移动来查看这个函数，这就已经给我们的开发者造成很不好的体感了，更不必谈设计模式和编程原则了。这样的函数往往都是逻辑混乱，甚至还有可能藏着 bug 在里面，是有很大的潜在风险的。所以以后看到这样的函数，就毫不犹豫地对它做一次优化吧。罗伯特·C·马丁（Robert C. Martin）在《敏捷软件开发：原则、模式与实践》中提出了单一职责原则（又称单一功能原则），结合这一原则，我们可以认为，一个函数应该只有一个引起变化的原因，应该只有一个职责。如果一个函数拥有过多职责，那么这个函数至少存在两个缺点。第一，任意一个职责的变化都可能削弱这个函数的能力；第二，对于使用者而言，为了使用函数中的其中一个职责，不得不把其他职责也包含进来，导致代码冗余，性能浪费。下面我们来看本次重构中出现的过长函数： async submit(needValidation = true) { // do something... // 大量的 if 语句... if (this.step == 5) { parameters.city_id = this.registerCityObj.cityId; parameters.zone_id = this.registerCityObj.zoneId; } if (this.step == 3 || this.step == 4) { parameters.vehicle_id = this.vehicleId; parameters.vehicle_body_color = '黑色'; } if (...){ // ... } const parameters = { ...parameters, ...this.value, }; const { data, ret } = await (this.registered ? fetchUpdateDriverInfo(parameters) : fetchSubmitJoinData(parameters)); // do something... } 上面的这个函数，我们可以很明显地看到很多 if 语句，这是需要警惕的地方，多个 if 语句的出现，往往就说明了这些语句正在形成各自的职责，正在瓜分函数的能力。这也是上面所提到的第二个缺点，只要调用这个函数，不论是谁，都必须先经过这些 if 语句，造成不必要的浪费。而且这个函数多达一百六十多行，读起来相当费劲，想要明白这个函数所处理的事情需要花一段时间。所以，有必要对这个函数进行拆解。下面我们通过提炼函数的方式来拆解这个函数 @BeforeCheck(() => !isSubmitting) private async handleSubmit() { // do something... // 提取的函数，对用户输入的值做格式化处理 this.handleFormatParams(); const parameters: IFetchSubmitJoinParams = { driver_id: String(this.driverId), step: this.step, // 提取的函数，对需要上传的图片做格式化处理 photo_item: this.handleFormatPhotoItemParams(), ...this.value, }; const { data } = await (this.registered ? fetchUpdateDriverInfo(parameters) : fetchSubmitJoinData(parameters)); // do something... } 通过提炼函数的方式，提炼出 handleFormatParams 和 handleFormatPhotoItemParams 方法，我们把一段一百多行的函数缩减为不到五十行。但提炼出来的函数中还充斥着大量的条件语句，这个我们放到下面全局变量中来说。全局变量伴随全局变量的常见问题：对全局数据的疏忽改变。你可以会在某处改变全局变量的值，而在别处又会错误地以为它仍保持着原值，这就是所谓的副作用。全局变量会损害模块性和可管理性。开发大于几百行规模软件的一个主要问题便是管理的复杂性，使其成这可管理的唯一办法便是将程序成为几个部分，以便每次只考虑其中的一个部分。模块化便是将程序分为几部分的最有力工具之一。 ——《代码大全》这里的全局变量指的是 Vue 中的 mixin，严格来说，mixin 也不算全局变量，但它有着和全局变量类似的缺点，甚至有过之而无不及。mixin 的存在让 Vue 实例被切割成两部分，两者之间可以轻易的互相调用。我自己就有被 mixin 教训过的经历，有一次在查一个页面获取的缓存值的问题，页面本身的存取逻辑没什么问题，浏览器的本地缓存也不应该会出什么问题，可为什么缓存里的值和预期的不一样呢？后来才发现，缓存用到的值在 mixin 中被改变了。这就是所谓的副作用。下面来看下本次重构中的部分 mixin 代码： created() { // do something... }, watch: { value: { handler: function(value) { // do something... }, deep: true, }, }, 在这个 mixin 中有生命周期函数以及 watch 监听。生命周期函数和 watch 具有自执行的能力，尤其是 watch，这里 watch 所监听的 value，是存放在各个具体的 Vue 实例中的，也就是说，任意一个 Vue 实例都可能不知道数据被改变了，因为数据是在 mixin 的 watch 中改变的。这些都是导致代码逻辑复杂混乱的重要原因。同时也如上面过长函数例子中看到，由于 mixin 需要作用于多个页面，从而增加了大量的条件语句。本次重构这里我们把各个页面需要用到 mixin 中的变量和函数还原到页面本身中，从而阻止了各个页面之间的相互污染，同时也可以处理掉多数的条件语句。来看下面一组对比原 mixin 中对请求参数处理的代码： if (this.photoValue) { // do something... for (const key of Object.keys(this.photoValue)) { // do something... if (value) { // do something... if (this.photoType[key] == 40) { // do something... } if (this.photoType[key] == 43) { // do something... } // if 语句省略... } } if (this.step == 20 ) { // do something... } // do something... } // 提交的文本信息 if (this.value) { for (const key of licenseIDArray) { if (this.value[key]) { // do something... } } // do something } if (this.step === 20 && !this.registered) { // do something... } // ... } 提炼函数放到页面本身中的请求参数处理代码： private handleFormatPhotoItemParams() { const photoItem = []; for (const key of Object.keys(this.photoValue)) { const value = this.photoValue[key]; if (value) { // do something... } } return JSON.stringify(photoItem); } private handleFormatParams() { this.value.driver_license = this.value.driver_license.toUpperCase(); } 通过这种方式，我们把代码变得更简洁，逻辑更清晰，各个页面之间相互独立，不会造成不必要的污染。响应拦截如果你在一个以上的地点看到相同的代码结构，那么可以肯定：设法将它们合而为一，程序会变得更好。——《重构：改善既有代码的设计》这里的响应拦截所具体所体现的是代码重复问题。重复的代码降低我们的工作效率，所谓牵一发而动全身，一旦数据格式有改变，所有的重复代码都得改一次。我们来看其中一个请求接口的函数： async fetchLunaImg(photoList) { const { error, data } = await fetchLunaImg(parameters); if (error || data.ret != 0) { return this.$toast.fail((data && data.msg) || '网络错误'); } // do something } 上面代码是改造前的请求接口函数的通用格式，每个请求都会单独对错误码进行处理，这次改造我们把对错误码的处理放到响应拦截器中，减少这些不必要的重复代码。需要对个别错误码进行处理的，我们放到 catch 中处理。以下是改造后的代码 // 添加响应拦截器 instance.interceptors.response.use( (response) => { // do something... }, (error) => { Toast.clear(); const config = (error.response || {}).config || {}; if (config.showError !== false) { Toast(error.message || '系统错误'); } return Promise.reject(error); }, ); // 接口调用 private async handleSubmit() { try { await fetchSubmitJoinData(parameters)); // do something... } catch (error: any) { // 对 15008 错误码单独处理 if (error.response.data.ret === 15008) { // do something... } } 链路过长如果你看到用户向一个对象请求另一个对象，然后再向后者请求另一个对象，然后再请求另一个对象......这就是消息链。在实际代码中你看到的可能是一长串的取值函数或一长串临时变量。采取这种方式，意味客户端代码将与查找过程中的导航结构紧密耦合。一旦对象间的关系发生任何变化，客户端就不得不作出相应的修改。——《重构：改善既有代码的设计》这里的链路过长所反映的是在不同组件之间调用路径过长的问题，这种情况导致了组件之间的耦合度过高，一旦组件之间的调用关系发生改变，整条消息链都有可能崩溃。以上传证件为例子，先来看看改造前的流程点击上传图片，imgUpload 组件触发父页面的 clickUpload 方法；父页面改变 activeImageId 值； documentUpload 组件根据 activeImageId 显示对应的示例图片；点击 documentUpload 中的上传图片，触发父页面 mixin 中的 upload方法； mixin 中的 upload方法通过 ref 的方式调用 imgUpload 中的 upload 方法； imgUpload 调用相机或选择图片上传；图片上传成功后，触发父页面的 change 方法和 ocrImg 方法；父页面通过 change 更新图片路径，通过 ocrImg 进行 ocr 识别。 // 1. 点击上传图片，imgUpload 组件触发父页面的 clickUpload 方法 clickUpload() { this.$emit('clickUpload'); } // 2. 父页面改变 activeImageId 值 // 3. documentUpload 组件根据 activeImageId 显示对应的示例图片 // 4. 点击 documentUpload 中的上传图片，触发父页面 mixin 中的 upload方法 upload() { this.$emit('upload', this.type, 'camera'); }, // 5. mixin 中的 upload方法通过 ref 的方式调用 imgUpload 中的 upload 方法 upload(type, action) { this.$refs[this.activeImageId][0].upload(); } // 6. imgUpload 调用相机或选择图片上传 upload(type, action, imageId) { this.appUploadImg(action); }, // 7. 图片上传成功后，触发父页面的 change 方法和 ocrImg 方法 async uploadImg(base64) { this.$emit('change', img); // 更新图片路径 this.$emit('ocrImg'); // 发起OCR识别请求 }, // 8. 父页面通过 change 更新图片路径，通过 ocrImg 进行 ocr 识别 async ocrImg(item) { const { data } = await fetchOCRinfo(parameters); }, 通过观察发现，链路过长的原因是图片上传组件和图片示例组件分开了，所以我们这两个组件合到一起，缩短调用链路，减少不必要的跳转。下面是改造后的流程点击上传图片，imgUploader 组件显示对应的示例图片；点击 imgUploader 中的上传图片，调用相机或选择图片上传；图片上传成功后，触发父页面的 handleChangePhoto 方法；父页面更新图片路径，并调用 ocr。 // 1. 点击上传图片，imgUploader 组件显示对应的示例图片 private handleShowSample() { this.showSample = true; } // 2. 点击 imgUploader 中的上传图片，调用相机或选择图片上传 private handlePictureAction() { // do something... } // 3. 图片上传成功后，触发父页面的 handleChangePhoto 方法 @Emit('changeValue') private async handleUploadImg(base64: string) { const params = { code_base64: encodeURI(base64), }; const { data } = await fetchImgUpload(params); // do something... return data.file_name; } // 4. 父页面更新图片路径，并调用 OCR private handleChangePhoto(id: string, value: string) { this.photoValue[id] = value; this.handleOcr(id); } 通过流程图就可以清晰地看到，改造后比改造前的链路要短了许多，这不仅有利于我们对代码的理解，也为后续可能发生改变的迭代先除去不少坑。总结以上就是本次重构的主要内容，分别从神秘代码、过长函数、全局变量、响应拦截和链路过长五种情况来讲述，这五种情况主要立足于代码的可阅读性、可维护性（可管理性）、代码性能和开发效率四个方面来展开。重构可以很大，本次重构引入了 Typescript，这对整个代码框架都会有影响，重构也可以很小，小到对文件名做了统一的规范。大有大做，小有小做。切勿因为太小而觉得不值得做，所谓合抱之木，生于毫末；九层之台，起于累土。小小的重构堆积起来也可以从根本上改善代码的质量。切勿因为太大而不敢去做，所谓不破不立，破而后立，一次大的重构可以让代码脱胎换骨，一次好的重构足以让代码披坚执锐，上阵杀敌。最后引用唐朝神秀禅师一偈语与大家共勉：时时勤拂拭，莫使惹尘埃。参考 [1] （美）马丁·福勒（Martin Fowler）. 重构：改善既有代码的设计：第2版[M].熊节，林从羽. 北京：人民邮电出版社，2019. [2] Steve McConnell. 代码大全[M].天奥. 北京：学苑出版社，1993. [3] （美）Andy Hunt，Venkat Subramaniam. 高效程序员的45个习惯：敏捷开发修炼之道[M].钱安川，郑柯. 北京：人民邮电出版社，2010.x

life.caoover 4 years

React 18 新增的几种hooks

React 18 新增的几种hooks React 18 已经发布好几个月了，在这篇文章中，我们来聊一下 React 18 中新增的那些 hooks，以及它们的使用场景。 useTransition 卡顿问题开发前端应用的过程中，有时点击按钮或者在输入框输入内容这样一个很小的操作就会导致视图的大量更新，这些更新同时进行时就可能导致页面的卡顿。如果我们能够将视图更新按紧急程度区分开来，让紧急的更新先完成渲染，不紧急的更新后完成渲染，就可以解决页面渲染卡顿的问题。 transition 就是 React 用来区分紧急更新和非紧急更新的一个新概念。紧急更新（urgent updates）反映直接的交互，比如输入、点击、长按等。非紧急更新（transition updates）将 UI 从一个视图切换到另一个视图。比如下面这个例子： const allItems = Array(5e6) .fill(null) .map((_, index) => index + 1); function filterItems(value: string) { let matchedItems; if (!value) { matchedItems = allItems; } else { matchedItems = allItems.filter((item) => String(item).includes(value)); } return matchedItems.slice(0, 100).map((item) => `item ${item}`); } function ItemList({ list }: { list: string[] }) { return ( <ul> {list.map((item) => ( <li key={item}>{item}</li> ))} </ul> ); } export default function UseTransitionDemo() { const [value, setValue] = useState(''); const listNode = useMemo(() => { const items = filterItems(value); return <ItemList list={items} />; }, [value]); const handleChange: InputProps['onChange'] = (e) => { setValue(e.target.value); }; return ( <div> <Input value={value} onChange={handleChange} /> {listNode} </div> ); } 页面上有一个输入框，在输入内容时需要做大量的计算来决定页面需要显示的内容。输入效果如下图，输入过程中，页面就发生卡顿，输入框的内容也没有即时地显示出来。输入结束后一段时间，页面的更新才渲染出来。然后我们将上面的例子使用 useTransition 修改一下： export default function UseTransitionDemo() { const [value, setValue] = useState(''); const [filterValue, setFilterValue] = useState(''); const [isPending, startTransition] = useTransition(); const listNode = useMemo(() => { const items = filterItems(filterValue); return <ItemList list={items} />; }, [filterValue]); const handleChange: InputProps['onChange'] = (e) => { setValue(e.target.value); startTransition(() => { setFilterValue(e.target.value); }); }; return ( <div> <Input value={value} onChange={handleChange} /> <div>isPending: {String(isPending)}</div> {listNode} </div> ); } 输入框内容的更新 setValue(e.target.value) 保持不变，而会导致大量计算的过滤值的更新用 startTransition 包起来标记为非紧急更新。输入效果如下，输入框内容的更新将会即时显示，页面也不再有卡顿的感觉。异步加载时的用户体验问题考虑下面的例子： const delay = (ms: number) => { return new Promise((resolve) => { setTimeout(() => { resolve(null); }, ms); }); }; const TabA = lazy(() => delay(1000).then(() => import('./tab-a'))); const TabB = lazy(() => delay(1000).then(() => import('./tab-b'))); export default function SuspenseTransition() { const [tab, setTab] = useState<'a' | 'b'>('a'); const handleSetTab: RadioGroupProps['onChange'] = (e) => { setTab(e.target.value); }; return ( <div> <div> <Radio.Group optionType='button' value={tab} onChange={handleSetTab}> <Radio value={'a'}>tab a</Radio> <Radio value={'b'}>tab b</Radio> </Radio.Group> </div> <Suspense fallback={<Spin />}> <div>{tab === 'a' ? <TabA /> : <TabB />}</div> </Suspense> </div> ); } 页面上有一个 tabs，每个 tab 下面的内容都是一个异步加载的组件（为了视觉效果，异步组件的加载加了 1 s 延迟）。从 tab a 切换到 tab b 时，在 TabB 组件异步加载的过程中，Suspense 会显示 fallback 的内容 Spin。这从逻辑上没有问题，但是在 TabB 组件异步加载的过程中，如果页面上能够继续显示 TabA 的内容，会有一个更好的用户体验。 useTransition 的另一个用途就是基于 transition 中的更新不会导致重新 suspended 的内容显示 fallback。用 transition 改造后的示例如下： export default function SuspenseTransition() { const [tab, setTab] = useState<'a' | 'b'>('a'); const [isPending, startTransition] = useTransition(); const handleSetTab: RadioGroupProps['onChange'] = (e) => { startTransition(() => { setTab(e.target.value); }); }; return ( <div> <div> <Radio.Group optionType="button" value={tab} onChange={handleSetTab}> <Radio value={'a'}>tab a</Radio> <Radio value={'b'}>tab b</Radio> </Radio.Group> </div> <Suspense fallback={<Spin />}> <div style={{ opacity: isPending ? 0.5 : 1 }}> {tab === 'a' ? <TabA /> : <TabB />} </div> </Suspense> </div> ); } tab 切换效果如下，从 tab a 切换到 tab b 时，在 TabB 组件加载完成之前可以一直显示 TabA 的内容。 useDeferredValue useDeferredValue 接收一个值，返回这个值的一个备份。在组件更新时，这个备份的最新值将延迟到紧急更新完成后才生效。也就是说，一个紧急更新导致的组件重新渲染，useDeferredValue 会先返回一个旧值来完成渲染，在紧急更新完成后，才会使用新值来重新渲染。 useDeferredValue 和 useTransition 能够实现的效果是相似的，都是用来让紧急更新先完成，让非紧急更新后完成。将前面使用 useTransition 解决卡顿问题的例子改为用 useDeferredValue 来实现如下： export default function UseDeferredValueDemo() { const [value, setValue] = useState(''); const deferredValue = useDeferredValue(value); const listNode = useMemo(() => { const items = filterItems(deferredValue); return <ItemList list={items} />; }, [deferredValue]); const handleChange: InputProps['onChange'] = (e) => { setValue(e.target.value); }; return ( <div> <Input value={value} onChange={handleChange} /> {listNode} </div> ); } useId useId 可以用来在服务端和客户端生成稳定的唯一 id，解决 hydration 过程中 id 不匹配问题。简单的使用案例如下： function UseIdDemo() { const id = useId(); return ( <> <label htmlFor={id}>Do you like React?</label> <input id={id} type="checkbox" name="react"/> </> ); }; 当组件中需要使用多个 id 时，将 useId() 生成的 id 作为前缀即可： function UseIdDemo() { const id = useId(); return ( <div> <label htmlFor={id + '-firstName'}>First Name</label> <div> <input id={id + '-firstName'} type="text" /> </div> <label htmlFor={id + '-lastName'}>Last Name</label> <div> <input id={id + '-lastName'} type="text" /> </div> </div> ); } useSyncExternalStore useSyncExternalStore 是用来订阅和读取外部数据源的 hooks，并且兼容并发渲染。一般是用来给库的作者使用的，比如 react-redux。关于为什么需要这样一个 hooks，考虑下面这个外部数据源： type Store<T> = ReturnType<typeof createStore<T>>; export function createStore<T>(initialState: T) { let state = initialState; const getState = () => state; const listeners = new Set<() => void>(); const setState = (fn: T | ((v: T) => T)) => { if (typeof fn === 'function') { state = (fn as (v: T) => T)(state); } else { state = fn; } listeners.forEach((l) => l()); }; const subscribe = (listener: () => void) => { listeners.add(listener); return () => { listeners.delete(listener); }; }; return { getState, setState, subscribe }; } export function useStore<T, S>(store: Store<T>, selector: (v: T) => S) { const [, forceUpdate] = useReducer(v => (v + 1), 0); useEffect(() => { const callback = () => forceUpdate(); return store.subscribe(callback); }, [store, selector]); return selector(store.getState()); } 我们用这个外部数据源来存储 input 的输入内容，然后在页面上将这个输入内容显示 10 次。这时候是没有任何问题的。 const store = createStore(''); function BlockText() { const text = useStore( store, useCallback((v) => v, []) ); return <div>{text}</div>; } function InputText() { const handleChange = (e: ChangeEvent<HTMLInputElement>) => { store.setState(e.target.value); }; return <input onChange={handleChange} /> } export default function UseSyncExternalStoreDemo() { return ( <div> <InputText></InputText> {Array(10) .fill(null) .map((_, index) => ( <BlockText key={index}></BlockText> ))} </div> ); } 但是当我们使用 startTransition 来开启并发渲染时（为了更好的演示渲染过程被中断的情况，我们在 BlockText 组件中加上 sleep(30) 来增加渲染的耗时）： const store = createStore(''); function sleep(ms: number) { const start = performance.now(); while (performance.now() - start < ms) {} } function BlockText() { const text = useStore( store, useCallback((v) => v, []) ); sleep(30); return <div>{text}</div>; } function InputText() { const handleChange = (e: ChangeEvent<HTMLInputElement>) => { startTransition(() => { store.setState(e.target.value); }); }; return <input onChange={handleChange} /> } 此时输入内容时 UI 的效果如下，可以看到 10 行内容显示有明显的不一致问题。 useSyncExternalStore 可以用来解决上面的不一致问题。我们使用 useSyncExternalStore 来重写外部数据源的 useStore 即可，这会强制 store 变更的同步完成，解决上面的不一致问题。 export function useStore<T, S>(store: Store<T>, selector: (v: T) => S) { return useSyncExternalStore( store.subscribe, useCallback(() => selector(store.getState()), [store, selector]) ); } useInsertionEffect useInsertionEffect 是给 CSS-in-JS 库添加样式使用的，可以解决渲染时添加样式的性能问题。 function useCSS(rule) { useInsertionEffect(() => { if (!isInserted.has(rule)) { isInserted.add(rule); document.head.appendChild(getStyleForRule(rule)); } }); return rule; } function Component() { let className = useCSS(rule); return <div className={className} />; } 参考文档 https://reactjs.org/docs/hooks-reference.html https://reactjs.org/blog/2022/03/29/react-v18.html https://github.com/reactjs/rfcs/blob/main/text/0212-react-18.md https://github.com/reactwg/react-18/discussions/41 https://github.com/reactjs/rfcs/blob/main/text/0213-suspense-in-react-18.md https://github.com/reactwg/react-18/discussions/69

life.caoover 4 years

图片处理在前端项目中的实践，包含涂抹、裁切、打码等

图片处理在前端项目中的实践，包含涂抹、裁切、打码等方案避免重复造轮子，首选现成的开源工具。大致有两种类型：集涂抹、裁切、滤镜、文字编辑等功能于一体的多合一工具库，如 tui.image-editor。单一打码功能小工具 image-mosaic 综合考虑功能需求、界面交互风格、库代码量、接入复杂度，选择单一打码功能的小工具，源码不到200 行，非常轻量，无需查阅复杂文档，有问题也方便排查处理。原理简介由于后续整体功能的实现需要对库源码稍作调整，此处先梳理下所用库的实现原理，简单描述就是将待处理的图片绘制到 canvas 上，然后将整个画布分为若干行、列，每个行列交叉形成一个小方块，当选中指定区域的小方块时，读取小方块内所有像素点的 rgba 信息进行均值计算，得到新的 rgba 值用于绘制小方块区域，从而形成马赛克图样。接着看看库源码中几个比较核心的方法实现：前置了解：canvas 上绘制的图像，可以通过其 context 的 getImageData 方法获取到像素点信息，得到的是一组数组形式的数据，每个像素点的 rgba 属性在数组中连续列出, 所以对像素点进行处理时，遍历像素数组每四个遍历项即得到一个像素点的 rgba 值。初始化数据在 class Mosaic 的 constructor 中，通过实例化时传入 canvas 的 context 和马赛克方块( tile )宽高尺寸，对整个画布按 tile 的像素宽高为基本单位划分行、列，每一个行列的交叉点就是一个 tile, 对于每一个 tile，使用对象对其进行描述，属性包括 tile 所在行、列、像素宽高以及对应 tile 在画布上的像素集合。最终得到实例属性 tiles，一个包含了所有的 tile 对象的数组。 class Mosaic { constructor(context, { tileWidth = 10, tileHeight = 10, brushSize = 3 } = {}) { const { canvas } = context; this.context = context; this.brushSize = brushSize; this.width = canvas.width; this.height = canvas.height; this.tileWidth = tileWidth; this.tileHeight = tileHeight; const { width, height } = this; this.imageData = context.getImageData(0, 0, width, height).data; this.tileRowSize = Math.ceil(height / this.tileHeight); this.tileColumnSize = Math.ceil(width / this.tileWidth); this.tiles = []; // All image tiles. // Set tiles. for (let i = 0; i < this.tileRowSize; i++) { for (let j = 0; j < this.tileColumnSize; j++) { const tile = { row: i, column: j, pixelWidth: tileWidth, pixelHeight: tileHeight, }; if (j === this.column - 1) { // Last column tile.pixelWidth = width - (j * tileWidth); } if (i === this.row - 1) { // Last row tile.pixelHeight = height - (i * tileHeight); } // Set tile data; const data = []; const pixelPosition = this.width * 4 * this.tileHeight * tile.row + tile.column * this.tileWidth * 4; for (let i = 0, j = tile.pixelHeight; i < j; i++) { const position = pixelPosition + this.width * 4 * i; data.push.apply(data, this.imageData.slice(position, position + tile.pixelWidth * 4)); }; tile.data = data; this.tiles.push(tile); } } } ... } 根据 tile 绘制改变像素根据 tiles 进行绘制，每一个 tile 的 data 中存储着图片在对应区块的像素点信息，绘制操作时，使用均值处理的方式，把每个 tile 中的像素点的 rgba 值分别加总，然后除以 tile 的像素点数，得到平均的 rgba 值用于填充对应 tile 的像素区域，这样的计算方式简单，新覆盖的颜色值跟原始色块的差距不会很大，修改后画面看起来不会很突兀。 class Mosaic { // ... drawTile(tiles) { tiles = [].concat(tiles); tiles.forEach((tile) => { if (tile.isFilled) { return false; // Already filled. } if (!tile.color) { let dataLen = tile.data.length; let r = 0, g = 0, b = 0, a = 0; for (let i = 0; i < dataLen; i += 4) { r += tile.data[i]; g += tile.data[i + 1]; b += tile.data[i + 2]; a += tile.data[i + 3]; } // Set tile color. let pixelLen = dataLen / 4; tile.color = { r: parseInt(r / pixelLen, 10), g: parseInt(g / pixelLen, 10), b: parseInt(b / pixelLen, 10), a: parseInt(a / pixelLen, 10), }; } const color = tile.color; this.context.fillStyle = `rgba(${color.r}, ${color.g}, ${color.b}, ${color.a / 255})`; const x = tile.column * this.tileWidth; const y = tile.row * this.tileHeight; const w = tile.pixelWidth; const h = tile.pixelHeight; this.context.clearRect(x, y, w, h); // Clear. this.context.fillRect(x, y, w, h); // Draw. tile.isFilled = true; }); } // ... } 通过指定坐标点得到对应区域 tile 在实际操作中，用户通常通过鼠标点触或连续滑动来进行指定区域的涂抹，那么就需要能够根据鼠标在画布上操作的坐标点得到对应区域的 tile，然后通过前面介绍的 drawTile 方法来绘制。结合初始化实例传入的画笔尺寸 brushSize，即可得到不同起始行、列所围区域的一组 tiles。 class Mosaic { ... getTilesByPoint(x, y, isBrushSize = true) { const tiles = []; if (isBrushSize) { /** 纵坐标值除以tileHeight得到截至该坐标的行数 *再减去brushSize的一半得到起始行数 *与0比较是边缘情况的处理，防止计算结果小于最小起始行 **/ let brushSize = this.brushSize; let startRow = Math.max(0, Math.floor(y / this.tileHeight) - Math.floor(brushSize / 2)); let startColumn = Math.max(0, Math.floor(x / this.tileWidth) - Math.floor(brushSize / 2)); let endRow = Math.min(this.tileRowSize, startRow + brushSize); let endColumn = Math.min(this.tileColumnSize, startColumn + brushSize); // Get tiles. while (startRow < endRow) { let column = startColumn; while (column < endColumn) { tiles.push(this.tiles[startRow * this.tileColumnSize + column]); column += 1; } startRow += 1; } } return tiles; } ... } 擦除还原从前面的介绍可以知道，每个 tile 的 data 中存有对应区块的原始像素信息，擦除时取出原始信息，使用context 的 createImageData 方法创建新的像素对象，然后将原始像素信息赋值其中，再使用putImageData 方法绘制回画布中，从而达到橡皮擦还原的效果，将所有被操作过的 tile 传入其中处理，即可还原整个画布上的马赛克。 class Mosaic { // ... eraseTile(tiles) { [].concat(tiles).forEach((tile) => { const x = tile.column * this.tileWidth; const y = tile.row * this.tileHeight; const w = tile.pixelWidth; const h = tile.pixelHeight; var imgData = this.context.createImageData(w, h); tile.data.forEach((val, i) => { imgData.data[i] = val; }) this.context.clearRect(x, y, w, h); // Clear. this.context.putImageData(imgData, x, y); // Draw. tile.isFilled = false; }); } ... ... } 扩展问题从上面的原理介绍中可以看出，所用小工具已经能满足我们所需要的核心打码功能，但是距离完成完整的目标功能还需进一步扩展，比如实际场景中用户编辑一张图片需要对不同地方使用不同尺寸的马赛克方块，比如汽车尾部喷漆式的大号车牌字体，用小马赛克方块涂抹会导致整体看起来还是可辨认的轮廓，而对于证件照片上的小字体，又需要使用比较小的笔触来涂抹，而笔触尺寸是一开始初始化实例时传入的参数，那么要如何在编辑同一张图片时动态切换不同尺寸笔触呢？尝试直接以新尺寸参数重新 new 实例 changeSize(value) { const canvas = this.$refs.canvas const ctx = canvas.getContext('2d') const newInstance = new Mosaic(ctx, { tileWidth: value, tileHeight: value, }) this.mosaic = newInstance } 结果是可行的，但存在两个擦除还原问题：由于擦除功能需要依赖对应的 tile 中存储的像素信息做还原，新 new 的实例的 tiles 中没有原来的像素信息，会导致切换笔触后无法还原切换笔触前产生的马赛克，所以继续修改，重新 new 实例时将新旧实例的 tiles 合并 newInstance.tiles = newInstance.tiles.concat(this.mosaic.tiles) 原始的还原方法实现中，是以实例的 tileWidth、tileHeight 属性进行坐标计算，那么当新实例执行还原计算时，以新实例的 tileWidth 等属性计算坐标，遍历使用的却是旧实例的 tile，会产生错乱，只需修改原始实现的两处取值为 tile 自身存储的属性即可解决： eraseTile(tiles) { [].concat(tiles).forEach((tile) => { + const x = tile.column * tile.pixelWidth; + const y = tile.column * tile.pixelHeight; - const x = tile.column * this.tileWidth; - const y = tile.row * this.tileHeight; const w = tile.pixelWidth; const h = tile.pixelHeight; var imgData = this.context.createImageData(w, h); tile.data.forEach((val, i) => { imgData.data[i] = val; }) this.context.clearRect(x, y, w, h); // Clear. this.context.putImageData(imgData, x, y); // Draw. tile.isFilled = false; }); } 仅需修改 2 个源码中的变量，即可解决动态切换笔触的问题。逻辑填坑结束，继续来完善交互界面，我们可以使用 range bar 等控件来实现交互界面调整笔触，然后基于鼠标事件来控制画笔行为，在鼠标 mousedown 时激活绘制，在 mousemove 时不断传入坐标给实例方法进行绘制处理，在 mouseup 时停止绘制，最终仅需少量代码 + 自己实现简单的交互界面即可低成本实现功能需求，且易于维护，后续如果需要新的处理算法比如亮度、对比度调整等，也只需集成相应的处理类即可，在控制面板通过切换功能模式来激活不同的类进行使用。示例效果如下：

157

life.caoover 2 years

微前端实践和总结

微前端实践和总结背景因为团队内有一个很重要的应用，维护成本一直很高，开发体验极其不好，团队规划要在下半年完成该项目的微前端拆分，所以提前学习了微前端的概念与实现原理，总结出了这篇文章。什么是微前端微****前端一词于 2016 年底首次出现在 ThoughtWorks 技术雷达中。微前端理念就是将网站或 Web 应用程序视为由独立团队拥有的功能的组合。每个团队都有不同的业务领域或任务，一个团队可以从数据库到用户界面，端到端地开发其功能。它关心和专注于两个问题： 1、随着项目迭代应用越来越庞大，难以维护。 2、跨团队或跨部门协作开发项目导致效率低下的问题。微前端出现的背景和意义应用的架构设计以一个面向产品销售的大型中台项目为例，售前、售中、售后、报表等等能力都是业务运营需要的，他们需要的是能完成业务闭环的系统。固然一种能力一个系统似乎更符合低耦合、高内聚的技术思维，但是并不符合用户体验的需要。那么在微前端出现之前，面对这种需求，大多数的做法都是在同一个仓库中维护所有的业务能力，全部集成在一个 SPA（Single-page Application）中。少数的做法则是将大系统拆分成多个系统，在首页聚合所有子系统入口，即 MPA（Multi-page Application）第一种做法：优势：统一的权限管理代码复用十分便捷更好的用户体验劣势代码权限管控问题项目构建时间长需求发布相互阻塞代码 commit 混乱、分支混乱技术体系要求统一无法同时灰度多条产品功能代码回滚相互影响错误监控无法细粒度拆分第二种做法：优势：更符合低耦合、高内聚的技术思维构建时间长可以使用独立的技术栈仓库分支 commit 管理清晰功能互不影响劣势用户体验割裂，不断的跳转公共包基础库重复加载产品权限无法进行统一收敛第一种虽然提升了用户体验，但是可以看到日常开发极其痛苦：发布需求时被需求阻塞、无法局部灰度局部升级、项目遇到问题时回滚影响其他业务、无法快速引进新的技术体系提高生产力，项目的迭代和维护对于研发同学而言无疑是噩梦。而第二种做法虽然提升了开发体验，但却降低了用户体验。所以在这个背景下，传统的开发架构已经无法应对这类大型项目的开发，微前端架构模式应运而生。微前端架构主流方案现在社区主流的方案主要有以下几类：拆分为基座应用、子应用，由基座应用负责加载子应用，代表方案有 qiankun 、 micro-app 、 garfish 去中心化方案，基于 module federation ，代表方案有 emp iframe 浏览器原生隔离优劣对比方案优势劣势中心化方案最主流的解决方案，相对成熟，接入代价小，遇到问题基本都有解决方案公用包、公用组件、公用库相对困难 module federation 全新的代码复用方式，完善的公用包、公用组件、公用库复用方案接入代价相对大，与构建强关联，老项目接入需要改造构建脚本。 iframe 简单粗暴 1. 性能差2. 应用间通信繁琐核心实现原理微前端的核心价值在于每个应用间技术栈无关、独立开发、独立部署、独立运行。那么我们要解决的的问题有以下几个：应用的注册与渲染基座应用和子应用代码运行在同一个环境，需要实现沙箱来实现应用间的隔离样式的隔离本文下面会讲解这些核心能力的实现原理。虽然笔者主要参考自 micro-app 的实现，但各个框架的这些能力的实现方式大同小异，可以当成通用知识学习。应用的注册与渲染在有了基座应用后，需要先注册好子应用的信息，然后才能对子应用的加载、渲染、卸载实现管理。主要需要以下几个信息：应用名称，一个应用名称对应一个应用，不可重复 url，即应用的加载地址以 micro-app 的实现为例，因为 micro-app 是基于 Web Components 实现的，所以应用的创建即组件的创建，所以首先，需要通过customElements创建一个自定义元素，并在 connectedCallback（元素被插入到DOM时执行）函数中执行初始化应用的操作，并在 disconnectedCallback（元素从DOM中删除时执行）函数中执行应用的卸载，所以我们还需要定义一个class 来管理应用的实例，并实现应用创建、加载与卸载的逻辑。 export class MyElement extends HTMLElement { // 声明需要监听的属性名，只有这些属性变化时才会触发attributeChangedCallback static get observedAttributes () { return ['name', 'url'] } constructor() { super(); } connectedCallback() { // 元素被插入到DOM时执行，此时去加载子应用的静态资源并渲染 console.log('micro-app is connected') // 创建微应用实例 const app = new CreateApp({ name: this.name, url: this.url, container: this, }) } disconnectedCallback () { // 元素从DOM中删除时执行，此时进行一些卸载操作 console.log('micro-app has disconnected') } attributeChangedCallback (attr, oldVal, newVal) { // 元素属性发生变化时执行，可以获取name、url等属性的值 console.log(`attribute ${attrName}: ${newVal}`) } } /** * 注册元素 * 注册后，就可以像普通元素一样使用micro-app，当micro-app元素被插入或删除DOM时即可触发相应的生命周期函数。 */ window.customElements.define('micro-app', MyElement) // 创建微应用 export default class CreateApp { constructor () { super() } status = 'created' // 组件状态，包括 created/loading/mount/unmount // 存放应用的静态资源 source = { links: new Map(), // link元素对应的静态资源 scripts: new Map(), // script元素对应的静态资源 } // 资源加载完时执行 onLoad () {} /** * 资源加载完成后进行渲染 */ mount () {} /** * 卸载应用 * 执行关闭沙箱，清空缓存等操作 */ unmount () {} } 在完成上面的定义后，不难看出，我们需要补充应用资源的加载与实现的逻辑。首先，需要去加载子应用的 html，并将 head 和 body 进行处理。 import { fetchSource } from './utils' export default function loadHtml (app) { fetchSource(app.url).then((html) => { html = html .replace(/<head[^>]*>[\s\S]*?<\/head>/i, (match) => { // 将head标签替换为micro-app-head，因为web页面只允许有一个head标签 return match .replace(/<head/i, '<micro-app-head') .replace(/<\/head>/i, '</micro-app-head>') }) .replace(/<body[^>]*>[\s\S]*?<\/body>/i, (match) => { // 将body标签替换为micro-app-body，防止与基座应用的body标签重复导致的问题。 return match .replace(/<body/i, '<micro-app-body') .replace(/<\/body>/i, '</micro-app-body>') }) // 将html字符串转化为DOM结构 const htmlDom = document.createElement('div') htmlDom.innerHTML = html console.log('html:', htmlDom) // 进一步提取和处理js、css等静态资源 extractSourceDom(htmlDom, app) }).catch((e) => { console.error('加载html出错', e) }) } 在获取完 html 之后，开始对 dom 进行遍历，处理 style , link , script 标签，获取子应用需要加载哪些远端资源。 /** * 递归处理每一个子元素 * @param parent 父元素 * @param app 应用实例 */ function extractSourceDom(parent, app) { const children = Array.from(parent.children) // 递归每一个子元素 children.length && children.forEach((child) => { extractSourceDom(child, app) }) for (const dom of children) { if (dom instanceof HTMLLinkElement) { // 提取css地址 const href = dom.getAttribute('href') if (dom.getAttribute('rel') === 'stylesheet' && href) { // 计入source缓存中 app.source.links.set(href, { code: '', // 代码内容 }) } // 删除原有元素 parent.removeChild(dom) } else if (dom instanceof HTMLScriptElement) { // 并提取js地址 const src = dom.getAttribute('src') if (src) { // 远程script app.source.scripts.set(src, { code: '', // 代码内容 isExternal: true, // 是否远程script }) } else if (dom.textContent) { // 内联script const nonceStr = Math.random().toString(36).substr(2, 15) app.source.scripts.set(nonceStr, { code: dom.textContent, // 代码内容 isExternal: false, // 是否远程script }) } parent.removeChild(dom) } else if (dom instanceof HTMLStyleElement) { // 进行样式隔离 } } } 然后开始请求资源并执行渲染，css 直接用 style 标签插入 dom 就好，script 我们需要在真正的 dom 节点挂载后依次执行。 /** * 获取link远程资源 * @param app 应用实例 * @param microAppHead micro-app-head * @param htmlDom html DOM结构 */ export function fetchLinksFromHtml (app, microAppHead, htmlDom) { const linkEntries = Array.from(app.source.links.entries()) // 通过fetch请求所有css资源 const fetchLinkPromise = [] for (const [url] of linkEntries) { fetchLinkPromise.push(fetchSource(url)) } Promise.all(fetchLinkPromise).then((res) => { for (let i = 0; i < res.length; i++) { const code = res[i] // 拿到css资源后放入style元素并插入到micro-app-head中 const link2Style = document.createElement('style') link2Style.textContent = code microAppHead.appendChild(link2Style) // 将代码放入缓存，再次渲染时可以从缓存中获取 linkEntries[i][1].code = code } // 处理完成后执行onLoad方法 app.onLoad(htmlDom) }).catch((e) => { console.error('加载css出错', e) }) } /** * 获取js远程资源 * @param app 应用实例 * @param htmlDom html DOM结构 */ export function fetchScriptsFromHtml (app, htmlDom) { const scriptEntries = Array.from(app.source.scripts.entries()) // 通过fetch请求所有js资源 const fetchScriptPromise = [] for (const [url, info] of scriptEntries) { // 如果是内联script，则不需要请求资源 fetchScriptPromise.push(info.code ? Promise.resolve(info.code) : fetchSource(url)) } Promise.all(fetchScriptPromise).then((res) => { for (let i = 0; i < res.length; i++) { const code = res[i] // 将代码放入缓存，再次渲染时可以从缓存中获取 scriptEntries[i][1].code = code } // 处理完成后执行onLoad方法 app.onLoad(htmlDom) }).catch((e) => { console.error('加载js出错', e) }) } // 创建微应用 export default class CreateApp { ... // 资源加载完时执行 onLoad (htmlDom) { this.loadCount = this.loadCount ? this.loadCount + 1 : 1 // 第二次执行且组件未卸载时执行渲染 if (this.loadCount === 2 && this.status !== 'unmount') { // 记录DOM结构用于后续操作 this.source.html = htmlDom // 执行mount方法 this.mount() } } /** * 资源加载完成后进行渲染 */ mount () { // 克隆DOM节点 const cloneHtml = this.source.html.cloneNode(true) // 创建一个fragment节点作为模版，这样不会产生冗余的元素 const fragment = document.createDocumentFragment() Array.from(cloneHtml.childNodes).forEach((node) => { fragment.appendChild(node) }) // 将格式化后的DOM结构插入到容器中 this.container.appendChild(fragment) // 执行js this.source.scripts.forEach((info) => { (0, eval)(info.code) }) // 标记应用为已渲染 this.status = 'mounted' } } 可以看到，所有的静态资源加载都是通过基座应用去请求的，所以在大多微前端框架的使用中，子应用必须支持跨域请求。可能会有同学会有疑惑为什么要做这么多工作来实现 js 与 css 的加载的劫持，直接获取地址插入 dom 让浏览器自行处理不就好了么？我们往后看，就会发现这其实这都是为后面沙箱的劫持与样式隔离的实现做铺垫。沙箱的实现常见沙箱实现主要有两种：快照实现，即在应用激活时保存，卸载时恢复这种实现其实原理很简单，下面我们来看 qiankun 的 snapshotSandbox 简单的实现 const iter = (window, callback) => { for (const prop in window) { if(window.hasOwnProperty(prop)) { callback(prop); } } } class SnapshotSandbox { constructor() { this.proxy = window; this.modifyPropsMap = {}; } // 激活沙箱 active() { // 缓存active状态的window this.windowSnapshot = {}; iter(window, (prop) => { this.windowSnapshot[prop] = window[prop]; }); Object.keys(this.modifyPropsMap).forEach(p => { window[p] = this.modifyPropsMap[p]; }) } // 退出沙箱 inactive(){ iter(window, (prop) => { if(this.windowSnapshot[prop] !== window[prop]) { // 记录变更 this.modifyPropsMap[prop] = window[prop]; // 还原window window[prop] = this.windowSnapshot[prop]; } }) } } 这种实现的优劣之处是显而易见的，优点在于实现简单，缺点在于性能差（每次激活与卸载都要遍历window 的所有属性）、无法实现同时多个实例。 proxy 实现，基于es6的属性劫持实现方案。 proxy 的使用无需多言，下面我们直接看简单实现 export default class ProxySandbox { active = false // 沙箱是否在运行 constructor() { const originWindow = window const fakeWindowMap = new Map() const proxy = new Proxy(fakeWindow, { set(target, p, value) { fakeWindowMap.set(p,value) return true }, get(target, p) { if(this.active){ return fakeWindowMap.get(p) || originWindow[p] }else{ return originWindow[p] } }, }) this.proxy = proxy } } 原理就是代理原生的 window，获取全局属性时从当前沙箱实例保存的 map 中获取。这样实现下，同时运行多个子应用，每个子应用就能在自己单独的沙箱环境下运行了。这只是简单演示实现原理，实际使用中还需要考虑全局事件监听等等诸多问题，对进一步实现有兴趣的可以去看各大框架的源码实现。那写完了沙箱的实现，在微前端框架中何时且如何使用它呢。上一节讲的执行加载 js 的过程，就可以把我们的沙箱劫持逻辑补充进去了。 import loadHtml from './source' + import Sandbox from './sandbox' export default class CreateApp { constructor ({ name, url, container }) { ... + this.sandbox = new Sandbox(name) } ... mount () { ... + this.sandbox.start() // 执行js this.source.scripts.forEach((info) => { (0, eval)(info.code) }) } /** * 卸载应用 * @param destory 是否完全销毁，删除缓存资源 */ unmount (destory) { ... + this.sandbox.stop() // destory为true，则删除应用 if (destory) { appInstanceMap.delete(this.name) } } } 我们需要将之前加载的 js，处理成下面的格式，来实现 window 的劫持。 (function(window, self) { with(window) { 子应用的js代码 } }).call(代理对象, 代理对象, 代理对象) 通过字符串拼接就可以实现 export default class ProxySandbox { ... // 修改js作用域 bindScope (code) { window. proxy = this. proxy return `;(function(window, self){with(window){;${code}\n}}).call(window.proxyWindow, window.proxyWindow, window.proxyWindow);` } } 这样，我们就实现了每个应用间 js 执行的环境隔离了。不难看出，这种实现在子应用使用浏览器中的原生 es module （比如 vite 的开发模式）的时候，就无能为力了。所以现在各大微前端框架在接入 vite 应用时，通常会要求将沙箱关闭，目前还没有看到社区中对这个问题有好的解决方案。样式隔离处理完了执行环境的隔离，那如何实现样式的隔离呢？有些同学可能马上就想到了 cssModule ，当然cssModule 可以解决样式隔离的问题，但是对于现有没有使用 cssModule 的应用来说就比较尴尬了，所以现有的框架大多都支持无感知实现样式的隔离。以 micro-app 为例子，打开官方示例,用 chrome devtools 查看样式就可以发现，它的样式隔离是通过给子应用中的css属性选择器都加上了micro-app[name=xxx]的前缀来实现的。具体的原理是什么呢，那就要提到一个相对比较冷门的api CSSRule 了，通过这个 api ，我们能获取到每个 style 内的所有 css 规则集合并进行处理。值得注意的是，实际使用中， CSSRule 实际也受浏览器同源策略的影响，而现代前端开发中，css 等静态资源通常会上传到不同源的 cdn 上，所以很少会有实际用到它的地方，但我们在渲染一节中，实现了 css 加载的劫持，并将请求到的 css 资源转换成 style 标签插入dom中，就可以不受同源策略的影响了～下面直接看代码，将我们获取的css放到一个新建的style标签添加到 dom 后，将其设置为 disabled (防止处理过程中对样式造成影响)，就可以通过 styleElement.sheet.cssRules 获取到这个 style 标签内所有的 css 规则，然后对规则的 selectorText（即选择器）加上对应子应用的前缀就可以实现我们想要的效果了。 /** * 依次处理每个cssRule * @param rules cssRule * @param prefix 前缀 */ function scopedRule (rules, prefix) { let result = '' // 遍历rules，处理每一条规则 for (const rule of rules) { switch (rule.type) { case 1: // STYLE_RULE result += scopedStyleRule(rule, prefix) break case 4: // MEDIA_RULE result += scopedPackRule(rule, prefix, 'media') break case 12: // SUPPORTS_RULE result += scopedPackRule(rule, prefix, 'supports') break default: result += rule.cssText break } } return result } /** * 修改CSS规则，添加前缀 * @param {CSSRule} rule css规则 * @param {string} prefix 前缀 */ function scopedStyleRule (rule, prefix) { // 获取CSS规则对象的选择和内容 const { selectorText, cssText } = rule // 处理顶层选择器，如 body，html 都转换为 micro-app[name=xxx] if (/^((html[\s>~,]+body)|(html|body|:root))$/.test(selectorText)) { return cssText.replace(/^((html[\s>~,]+body)|(html|body|:root))/, prefix) } else if (selectorText === '*') { // 选择器 * 替换为 micro-app[name=xxx] * return cssText.replace('*', `${prefix} *`) } const builtInRootSelectorRE = /(^|\s+)((html[\s>~]+body)|(html|body|:root))(?=[\s>~]+|$)/ // 匹配查询选择器 return cssText.replace(/^[\s\S]+{/, (selectors) => { return selectors.replace(/(^|,)([^,]+)/g, (all, $1, $2) => { // 如果含有顶层选择器，需要单独处理 if (builtInRootSelectorRE.test($2)) { // body[name=xx]|body.xx|body#xx 等都不需要转换 return all.replace(builtInRootSelectorRE, prefix) } // 在选择器前加上前缀 return `${$1} ${prefix} ${$2.replace(/^\s*/, '')}` }) }) } 然后我们将这段处理加到 css 的挂载过程中就可以实现样式隔离了。但是需要注意的是，还需要对 style 的插入进行处理，通常都是通过劫持全局的 createElement 等创建元素的方法或者使用MutationObserver api 监听 dom 的改变来实现。总结本文主要讲述我在学习微前端过程中的一些总结，并结合实例探讨了微前端框架几个核心能力的实现，碍于篇幅原因，很多细节没有提到。如果文章有错误或者不准确的地方，欢迎大家指正。引用 https://juejin.cn/post/7016911648656982024 https://github.com/bailicangdu/simple-micro-app https://juejin.cn/post/7004661323124441102

250

life.caoover 4 years

关于UserAgent

关于UserAgent 前言最近发现我们项目中对于 UserAgent 的识别判断方式各不一样，可能有数十种写法，而且涉及的前端项目众多。于是笔者打算对 UserAgent 进行一个总结。关于 UserAgent 定义在 W3C 上找到一个对 UserAgent 的定义 A user agent is any software that retrieves, renders and facilitates end user interaction with Web content, or whose user interface is implemented using Web technologies. 原文翻译的话，UserAgent 是一个“软件/载体”，它获取内容并呈现，同时帮助终端用户与 Web 内容进行交互，或者这个“软件/载体”本身的用户交互界面就是以 Web 技术来实现。英文字面翻译难免会有点生硬，没关系，因为在如今 UserAgent 更多指用户访问 Web 所用的设备特征。UserAgent 就是一个特征字符串，在 MDN 文档中可以看到它通常有如下的格式： Mozilla/ () () Mozilla 是一个通用标记符号，用来表示与 Mozilla 兼容，这几乎是现代浏览器的标配。 [system information]：系统与浏览器信息，如：Macintosh; Intel Mac OS X 10_15_7。 [platform]：用来说明浏览器所运行的原生系统平台（例如 Windows、Mac、Linux 或 Android），以及是否运行在手机上。 [platform details]：平台的其他补充信息，但各个浏览器为了兼容，这个字段没有实际意义，如：KHTML, like Gecko。 [extensions]：扩展字段，用于描述浏览器信息以及浏览器追加的自定义信息，如：Chrome/103.0.0.0 Safari/537.36。 APP 定制的 UserAgent 由于通常的 UserAgent 更多和系统平台相关，一些 APP 厂商也会定制 Webview 或在 UserAgent 中加入定制的一部分字符串。比如微信内打开 Webview 时，UserAgent 中会带有 MicroMessenger 或 Wechat 这样的字符串，而在小程序中打开 Webview 时，UserAgent 中会带有 miniProgram 这样的字符串，如何解析 UserAgent APP 在系统 UserAgent 末尾追加了一段定制的部分，内容包括：APP 版本号，系统，渠道名称，设备型号，设备信息等。因此，我们解析 UserAgent 的需求主要有以下三部分：系统信息：操作系统，操作系统版本 APP 信息：APP 包名，版本号，渠道名称设备信息：设备型号，可选的设备信息了解下开源方案我们可以在 github 上搜到很多关于 UserAgent 的仓库，Stars 较多的有这两个。 faisalman/ua-parser-js 此项目 Owner 维护十年了，值得称赞 fex-team/ua-device 百度 FEX 团队出品，更针对国内的浏览器和手机厂商从这两个项目上，我们可以意识到这两点： UserAgent 的实际情况非常复杂，解析是讲成功率的，很难有 100% 正确的情况解析 UserAgent 需要与时俱进，因为外部环境一直在变化

JavaScript中的发布-订阅模式发布-订阅模式，看似陌生，其实不然。工作中经常会用到，例如 Node.js EventEmitter 中的 on 和 emit 方法；Vue 中的 $on 和 $emit 方法；Dom 注册事件 document.addEventListener('click', (event) => {})。他们都使用了发布-订阅模式，让开发变得更加高效方便。一、什么是发布-订阅模式 1. 定义发布-订阅模式其实是一种对象间一对多的依赖关系，当一个对象的状态发送改变时，所有依赖于它的对象都将得到状态改变的通知。订阅者（Subscriber）把自己想订阅的事件注册（Subscribe）到调度中心（Event Channel），当发布者（Publisher）发布该事件（Publish Event）到调度中心，也就是该事件触发时，由调度中心统一调度（Fire Event）订阅者注册到调度中心的处理代码。 2. 例子比如我们很喜欢看某个公众号号的文章，但是我们不知道什么时候发布新文章，要不定时的去翻阅；这时候，我们可以关注该公众号，当有文章推送时，会有消息及时通知我们文章更新了。上面一个看似简单的操作，其实是一个典型的发布订阅模式，公众号属于发布者，用户属于订阅者；用户将订阅公众号的事件注册到调度中心，公众号作为发布者，当有新文章发布时，公众号发布该事件到调度中心，调度中心会及时发消息告知用户。二、如何实现发布-订阅模式？ 1. 实现思路创建一个对象在该对象上创建一个缓存列表（调度中心） on 方法用来把函数 fn 都加到缓存列表中（订阅者注册事件到调度中心） emit 方法取到 arguments 里第一个当做 event，根据 event 值去执行对应缓存列表中的函数（发布者发布事件到调度中心，调度中心处理代码） off 方法可以根据 event 值取消订阅（取消订阅） once 方法只监听一次，调用完毕后删除缓存函数（订阅一次） 2. 基础版我们来看个简单的 demo，实现了 on 和 emit 方法，代码中有详细注释。 // 公众号对象 let eventEmitter = {}; // 缓存列表，存放 event 及 fn eventEmitter.list = {}; // 订阅 eventEmitter.on = function (event, fn) { let _this = this; // 如果对象中没有对应的 event 值，也就是说明没有订阅过，就给 event 创建个缓存列表 // 如有对象中有相应的 event 值，把 fn 添加到对应 event 的缓存列表里 (_this.list[event] || (_this.list[event] = [])).push(fn); return _this; }; // 发布 eventEmitter.emit = function () { let _this = this; // 第一个参数是对应的 event 值，直接用数组的 shift 方法取出 let event = [].shift.call(arguments), fns = [..._this.list[event]]; // 如果缓存列表里没有 fn 就返回 false if (!fns || fns.length === 0) { return false; } // 遍历 event 值对应的缓存列表，依次执行 fn fns.forEach(fn => { fn.apply(_this, arguments); }); return _this; }; function user1 (content) { console.log('用户1订阅了:', content); }; function user2 (content) { console.log('用户2订阅了:', content); }; // 订阅 eventEmitter.on('article', user1); eventEmitter.on('article', user2); // 发布 eventEmitter.emit('article', 'Javascript 发布-订阅模式'); /* 用户1订阅了: Javascript 发布-订阅模式用户2订阅了: Javascript 发布-订阅模式 */ 3. 加强版这一版中我们补充了一下 once 和 off 方法。 let eventEmitter = { // 缓存列表 list: {}, // 订阅 on (event, fn) { let _this = this; // 如果对象中没有对应的 event 值，也就是说明没有订阅过，就给 event 创建个缓存列表 // 如有对象中有相应的 event 值，把 fn 添加到对应 event 的缓存列表里 (_this.list[event] || (_this.list[event] = [])).push(fn); return _this; }, // 监听一次 once (event, fn) { // 先绑定，调用后删除 let _this = this; function on () { _this.off(event, on); fn.apply(_this, arguments); } on.fn = fn; _this.on(event, on); return _this; }, // 取消订阅 off (event, fn) { let _this = this; let fns = _this.list[event]; // 如果缓存列表中没有相应的 fn，返回false if (!fns) return false; if (!fn) { // 如果没有传 fn 的话，就会将 event 值对应缓存列表中的 fn 都清空 fns && (fns.length = 0); } else { // 若有 fn，遍历缓存列表，看看传入的 fn 与哪个函数相同，如果相同就直接从缓存列表中删掉即可 let cb; for (let i = 0, cbLen = fns.length; i < cbLen; i++) { cb = fns[i]; if (cb === fn || cb.fn === fn) { fns.splice(i, 1); break } } } return _this; }, // 发布 emit () { let _this = this; // 第一个参数是对应的 event 值，直接用数组的 shift 方法取出 let event = [].shift.call(arguments), fns = [..._this.list[event]]; // 如果缓存列表里没有 fn 就返回 false if (!fns || fns.length === 0) { return false; } // 遍历 event 值对应的缓存列表，依次执行 fn fns.forEach(fn => { fn.apply(_this, arguments); }); return _this; } }; function user1 (content) { console.log('用户1订阅了:', content); } function user2 (content) { console.log('用户2订阅了:', content); } function user3 (content) { console.log('用户3订阅了:', content); } function user4 (content) { console.log('用户4订阅了:', content); } // 订阅 eventEmitter.on('article1', user1); eventEmitter.on('article1', user2); eventEmitter.on('article1', user3); // 取消user2方法的订阅 eventEmitter.off('article1', user2); eventEmitter.once('article2', user4) // 发布 eventEmitter.emit('article1', 'Javascript 发布-订阅模式'); eventEmitter.emit('article1', 'Javascript 发布-订阅模式'); eventEmitter.emit('article2', 'Javascript 观察者模式'); eventEmitter.emit('article2', 'Javascript 观察者模式'); // eventEmitter.on('article1', user3).emit('article1', 'test111'); /* 用户1订阅了: Javascript 发布-订阅模式用户3订阅了: Javascript 发布-订阅模式用户1订阅了: Javascript 发布-订阅模式用户3订阅了: Javascript 发布-订阅模式用户4订阅了: Javascript 观察者模式 */ 三、 Vue 中发布-订阅的实现有了发布-订阅模式的知识后，我们来看下 Vue 中怎么实现 $on 和 $emit 的方法，实现思路大体相同，如上第二点中的第一条：Vue 中实现的方法支持订阅数组事件。直接看源码： function eventsMixin (Vue) { var hookRE = /^hook:/; Vue.prototype.$on = function (event, fn) { var this$1 = this; var vm = this; // event 为数组时，循环执行 $on if (Array.isArray(event)) { for (var i = 0, l = event.length; i < l; i++) { this$1.$on(event[i], fn); } } else { (vm._events[event] || (vm._events[event] = [])).push(fn); // optimize hook:event cost by using a boolean flag marked at registration // instead of a hash lookup if (hookRE.test(event)) { vm._hasHookEvent = true; } } return vm }; Vue.prototype.$once = function (event, fn) { var vm = this; // 先绑定，后删除 function on () { vm.$off(event, on); fn.apply(vm, arguments); } on.fn = fn; vm.$on(event, on); return vm }; Vue.prototype.$off = function (event, fn) { var this$1 = this; var vm = this; // all，若没有传参数，清空所有订阅 if (!arguments.length) { vm._events = Object.create(null); return vm } // array of events，events 为数组时，循环执行 $off if (Array.isArray(event)) { for (var i = 0, l = event.length; i < l; i++) { this$1.$off(event[i], fn); } return vm } // specific event var cbs = vm._events[event]; if (!cbs) { // 没有 cbs 直接 return this return vm } if (!fn) { // 若没有 handler，清空 event 对应的缓存列表 vm._events[event] = null; return vm } if (fn) { // specific handler，删除相应的 handler var cb; var i$1 = cbs.length; while (i$1--) { cb = cbs[i$1]; if (cb === fn || cb.fn === fn) { cbs.splice(i$1, 1); break } } } return vm }; Vue.prototype.$emit = function (event) { var vm = this; { // 传入的 event 区分大小写，若不一致，有提示 var lowerCaseEvent = event.toLowerCase(); if (lowerCaseEvent !== event && vm._events[lowerCaseEvent]) { tip( "Event \"" + lowerCaseEvent + "\" is emitted in component " + (formatComponentName(vm)) + " but the handler is registered for \"" + event + "\". " + "Note that HTML attributes are case-insensitive and you cannot use " + "v-on to listen to camelCase events when using in-DOM templates. " + "You should probably use \"" + (hyphenate(event)) + "\" instead of \"" + event + "\"." ); } } var cbs = vm._events[event]; if (cbs) { cbs = cbs.length > 1 ? toArray(cbs) : cbs; // 只取回调函数，不取 event var args = toArray(arguments, 1); for (var i = 0, l = cbs.length; i < l; i++) { try { cbs[i].apply(vm, args); } catch (e) { handleError(e, vm, ("event handler for \"" + event + "\"")); } } } return vm }; } /*** * Convert an Array-like object to a real Array. */ function toArray (list, start) { start = start || 0; var i = list.length - start; var ret = new Array(i); while (i--) { ret[i] = list[i + start]; } return ret } 四、发布-订阅模式总结 1. 优点对象之间解耦异步编程中，可以更松耦合的代码编写 2. 缺点创建订阅者本身要消耗一定的时间和内存虽然可以弱化对象之间的联系，多个发布者和订阅者嵌套一起的时候，程序难以跟踪维护五、观察者模式定义一群观察者（Observers）观察监听某个被观察对象（Subject），当有关状态发生变化时，Subject 会通知这一系列 Observers 触发更新。可以理解为：一个班里的学生们都在听老师讲课，当老师布置任务时，会通知学生们都去执行。简单实现 function Subject(){ this.observers = []; } Subject.prototype = { // 添加观察者 add: function(observer) { this.observers.push( observer ); }, // 移除观察者 remove: function(observer) { var observers = this.observers; var len = observers.length; for(var i=0; i<len; i++){ if(observers[i] === observer) { observers.splice(i, 1); } } }, // 通知观察者 notify: function(){ var observers = this.observers; var len = observers.length; for(var i=0; i<len; i++){ observers[i].update(); } } } //观察者 function Observer(name) { this.name = name; } Observer.prototype = { //观察者监听到变化后要处理的逻辑 update: function(){ console.log('被通知了---我是观察者：', this.name); } } // 使用示例： var subject = new Subject(); var fdd = new Observer('fdd'); var fxx = new Observer('fxx'); subject.add(fdd); subject.add(fxx); subject.notify(); // 最终输出结果： // 被通知了---我是观察者： fdd // 被通知了---我是观察者： fxx 六、扩展（发布-订阅模式与观察者模式的区别）很多地方都说发布-订阅模式是观察者模式的别名，但是他们真的一样吗？是不一样的。这两个模式都是为了维护一系列观察者，当被观察者状态发生变更时，通知这一系列观察者去进行相应更新；然而也有一些区别，那就是发布订阅模式在发布者与订阅者之间多了一个消息管理器，使得发布者与订阅者解耦。如下图所示发布-订阅模式订阅者（Subscriber）把自己想订阅的事件注册（Subscribe）到调度中心（Event Channel），当发布者（Publisher）发布该事件（Publish Event）到调度中心，也就是该事件触发时，由调度中心统一调度（Fire Event）订阅者注册到调度中心的处理代码。观察者模式观察者（Observer）直接订阅（Subscribe）主题（Subject），而当主题被激活的时候，会触发（Fire Event）观察者里的事件。如下图差异在观察者模式中，观察者是知道 Subject 的，Subject 一直保持对观察者进行记录。然而，在发布订阅模式中，发布者和订阅者不知道对方的存在。它们只有通过消息代理进行通信。在发布订阅模式中，组件是松散耦合的，正好和观察者模式相反。观察者模式大多数时候是同步的，比如当事件触发，Subject 就会去调用观察者的方法。而发布-订阅模式大多数时候是异步的（使用消息队列）。观察者模式需要在单个应用程序地址空间中实现，而发布-订阅更像交叉应用模式。数据的双向绑定比如比较当下热门 vue 框架，里面不少地方都涉及到了观察者模式，比如：利用 Object.defineProperty() 对数据进行劫持，设置一个监听器 Observer，用来监听所有属性，如果属性上发上变化了，就需要告诉订阅者 Watcher 去更新数据，最后指令解析器 Compile 解析对应的指令，进而会执行对应的更新函数，从而更新视图，实现了双向绑定~ 子组件与父组件通信 Vue 中我们通过 props 完成父组件向子组件传递数据，子组件与父组件通信我们通过自定义事件即 $on,$emit来实现，其实也就是通过 $emit 来发布消息，并对订阅者 $on 做统一处理 ~ 七、大显身手自定义数据的双向绑定上面说到，vue 双向绑定是数据劫持和发布订阅做实现的，现在我们借助这种思想，自己来实现一个简单的数据的双向绑定，首先是要有页面结构 <div id="app"> <h3>数据的双向绑定</h3> <div class="cell"> <div class="text" v-text="myText"></div> <input class="input" type="text" v-model="myText" > </div> </div> 相信你已经知道了，我们要做到就是 input 标签的输入，通过 v-text 绑定到类名为 text 的 div 标签上这里我们需要创建一个类，这里就叫做 myVue 吧。 class myVue{ constructor (options){ // 传入的配置参数 this.options = options; // 根元素 this.$el = document.querySelector(options.el); // 数据域 this.$data = options.data; // 保存数据model与view相关的指令，当model改变时，我们会触发其中的指令类更新，保证view也能实时更新 this._directives = {}; // 数据劫持，重新定义数据的 set 和 get 方法 this._obverse(this.$data); // 解析器，解析模板指令，并将每个指令对应的节点绑定更新函数，添加监听数据的订阅者，一旦数据有变动，收到通知，更新视图 this._compile(this.$el); } } 这里我们定义了 myVue 构造函数，并在构造方法中进行了一些初始化操作，上面做了注释，这里我就不在赘述，主要来看里面关键的两个方法 _obverse 和 _compile。首先是 _observe 方法，他的作用就是处理传入的 data ，并重新定义 data 的 set 和 get 方法，保证我们在 data 发生变化的时候能跟踪到，并发布通知，主要用到了 Object.defineProperty() 这个方法，对这个方法还不太熟悉的小伙伴们，请猛点这里 _observe 实现 //_obverse 函数，对data进行处理，重写data的set和get函数 _obverse(data){ let val ; //遍历数据 for( let key in data ){ // 判断是不是属于自己本身的属性 if( data.hasOwnProperty(key) ){ this._directives[key] = []; } val = data[key]; //递归遍历 if ( typeof val === 'object' ) { //递归遍历 this._obverse(val); } // 初始当前数据的执行队列 let _dir = this._directives[key]; //重新定义数据的 get 和 set 方法 Object.defineProperty(this.$data,key,{ enumerable: true, configurable: true, get: function () { return val; }, set: function (newVal) { if ( val !== newVal ) { val = newVal; // 当 myText 改变时，触发 _directives 中的绑定的Watcher类的更新 _dir.forEach(function (item) { //调用自身指令的更新操作 item._update(); }) } } }) } } 上面的代码也很简单，注释也都很清楚，不过有个问题就是，我在递归遍历数据的时候，偷了个小懒，这里我只涉及到了一些简单的数据结构，复杂的例如循环引用的这种我没有考虑进入接着我们来看看 _compile 这个方法，它实际上是一个解析器，其功能就是解析模板指令，并将每个指令对应的节点绑定更新函数，添加监听数据的订阅者，一旦数据有变动，就收到通知，然后去更新视图变化，具体实现如下： _compile 实现 _compile(el){ //子元素 let nodes = el.children; for( let i = 0 ; i < nodes.length ; i++ ){ let node = nodes[i]; // 递归对所有元素进行遍历，并进行处理 if( node.children.length ){ this._compile(node); } //如果有 v-text 指令 , 监控 node的值并及时更新 if( node.hasAttribute('v-text')){ let attrValue = node.getAttribute('v-text'); //将指令对应的执行方法放入指令集 this._directives[attrValue].push(new Watcher('text',node,this,attrValue,'innerHTML')) } //如果有 v-model属性，并且元素是INPUT或者TEXTAREA，我们监听它的input事件 if( node.hasAttribute('v-model') && ( node.tagName === 'INPUT' || node.tagName === 'TEXTAREA')){ let _this = this; //添加input时间 node.addEventListener('input',(function(){ let attrValue = node.getAttribute('v-model'); //初始化赋值 _this._directives[attrValue].push(new Watcher('input',node,_this,attrValue,'value')); return function () { //后面每次都会更新 _this.$data[attrValue] = node.value; } })()) } } } 上面的代码也很清晰，我们从根元素 #app 开始递归遍历每个节点，并判断每个节点是否有对应的指令，这里我们只针对 v-text 和 v-model，我们对 v-text 进行了一次 new Watcher()，并把它放到了 myText 的指令集里面，对 v-model 也进行了解析，对其所在的 input 绑定了 input 事件，并将其通过 new Watcher() 与 myText 关联起来，那么我们就应该来看看这个 Watcher 到底是什么？ Watcher 其实就是订阅者，是 _observer 和 _compile 之间通信的桥梁用来绑定更新函数，实现对 DOM 元素的更新 Warcher 实现 class Watcher{ /* * name 指令名称，例如文本节点，该值设为"text" * el 指令对应的DOM元素 * vm 指令所属myVue实例 * exp 指令对应的值，本例如"myText" * attr 绑定的属性值，本例为"innerHTML" * */ constructor (name, el, vm, exp, attr){ this.name = name; this.el = el; this.vm = vm; this.exp = exp; this.attr = attr; //更新操作 this._update(); } _update(){ this.el[this.attr] = this.vm.$data[this.exp]; } } 每次创建 Watcher 的实例，都会传入相应的参数，也会进行一次 _update 操作，上述的 _compile 中，我们创建了两个 Watcher 实例，不过这两个对应的 _update 操作不同而已，对于 div.text 的操作其实相当于 div.innerHTML=h3.innerHTML = this.data.myText ，对于 input 相当于 input.value=this.data.myText , 这样每次数据 set 的时候，我们会触发两个 _update 操作，分别更新 div 和 input 中的内容测试初始化一下 //创建vue实例 const app = new myVue({ el : '#app' , data : { myText : 'hello world' } }) 接着，上图这样就顺利的实现了一个简单的双向绑定！

114

life.caoover 5 years

JSX、Template如何被解析的？

JSX、Template如何被解析的？最近正处于Vue转写React的过程中，对于React中如何转译JSX比较好奇，所以就有了下面的对比分析文章。 JSX 下面这段简单的JSX代码，在项目中配置好.babelrc后，再执行后 npx babel index.jsx -w -o index.js后就会转译成常见的js代码。 // .babelrc { "presets": ["@babel/preset-react"] } // jsx start... function formatName(user) { return user.firstName + ' ' + user.lastName; } let user = { firstName: 'Harper', lastName: 'Perez' }; let code = ( <h1> Hello, {formatName(user)}! </h1> ); // transformed js... function formatName(user) { return user.firstName + ' ' + user.lastName; } let user = { firstName: 'Harper', lastName: 'Perez' }; let code = /*#__PURE__*/React.createElement("h1", null, "Hello, ", formatName(user), "!"); 从Babel官网中，我们得知@babel/preset-react预设包含了 @babel/plugin-syntax-jsx、@babel/plugin-transform-react-jsx、@babel/plugin-transform-react-display-name三个插件，其中，**@babel/plugin-syntax-jsx给解析参数parserOpts中增加了plugins: ['jsx']，使Babel在parse过程中对JSX语法进行识别；@babel/plugin-transform-react-jsx**主要是对初步生成好的AST进行transform，比如将‘(hello,{formatName(user)}!)’生成的AST转换成'React.createElement(...codes...)'相应的AST。接下来会逐步介绍其中的过程。如上图所示，这段在@babel/core/lib/transformation/index.js的run函数展示了这次转换的主要流程： function* run(config, code, ast) { // parse解析 // (0, _normalizeOpts.default)(config) 这里会得知parserOpts解析参数，增加了plugins:['jsx'] const file = yield* (0, _normalizeFile.default)(config.passes, (0, _normalizeOpts.default)(config), code, ast); const opts = file.opts; // transform转换 try { yield* transformFile(file, config.passes); } catch (e) { } let outputCode, outputMap; // generate生成最终代码的过程 try { if (opts.code !== false) { ({ outputCode, outputMap } = (0, _generate.default)(config.passes, file)); } } catch (e) { } return { metadata: file.metadata, options: opts, ast: opts.ast === true ? file.ast : null, code: outputCode === undefined ? null : outputCode, map: outputMap === undefined ? null : outputMap, sourceType: file.ast.program.sourceType }; } @babel/plugin-transform-react-jsx 这个插件主要是在create-plugin.js文件中生成的。利用Babel插件机制，在遍历每个AST节点的时候，都会访问visitor函数，所以在该插件中，注册特定AST节点的enter、exit处理函数。（流程图） { name, inherits: _pluginSyntaxJsx.default, visitor: { Program: { enter(path, state) { // file对象是什么呢？请看下图 const { file } = state; // runtime---> 'classic' let runtime = RUNTIME_DEFAULT; let source = IMPORT_SOURCE_DEFAULT; // React.createElement let pragma = PRAGMA_DEFAULT; let pragmaFrag = PRAGMA_FRAG_DEFAULT; let sourceSet = !!options.importSource; let pragmaSet = !!options.pragma; let pragmaFragSet = !!options.pragmaFrag; set(state, "runtime", runtime); if (runtime === "classic") { const createElement = toMemberExpression(pragma); const fragment = toMemberExpression(pragmaFrag); set(state, "id/createElement", () => _core.types.cloneNode(createElement)); set(state, "id/fragment", () => _core.types.cloneNode(fragment)); set(state, "defaultPure", pragma === DEFAULT.pragma); } } }, // ... } } 在看上述代码之前，先来了解一下Babel解析后的AST，下图是一个简单的变量声明：接下来，再看看示例的代码块被Babel转化出来的AST节点，最外层是File对象，主要关注点在ast属性值里的program对象，这里描述了节点类型、代码所在的起始终止的位置、注释、以及body内的子节点等内容。 function formatName(user) { return user.firstName + ' ' + user.lastName; } 上述代码片段对应的就是以下类型为FunctionDeclaration函数声明的AST描述信息： let user = { firstName: 'Harper', lastName: 'Perez' }; 接下来是比较简单的变量声明：Identifier--->标识符-->'user'；'user'有两个属性properties，对应下面的properties节点： let code = ( <h1> Hello, {formatName(user)}! </h1> ); 下图是对JSX语法的解析：在该Node节点中，id所描述的是'code'，用Identifier描述符来表示；init节点表明初始化，包含children子节点、loc位置、openingElement开元素、closingElement闭合元素、leadingComments前置注释、innerComments内部注释、trailingComments后置注释等描述信息。以下是对于children、openingElement的详细内容，可以看到children子节点内包括JSXText、JSXExpressionContainer的节点信息。 JSXText的节点信息，描述起来比较简单，关注value、type属性即可。下图是JSXExpressionContainer的描述信息，内部有expression属性，包括了arguments属性，来描述函数参数，callee表明调用函数了解了代码的主体AST结构后，来分析program的enter函数了做了什么事情？其实主要是标记runtime运行时的模式为classic，以及生成React.createElement的AST节点，保存在state中，以便后续使用。下图就是React.createElement的描述信息： // 如何生成React.createElement的AST节点信息， // 感兴趣的可以参照以下代码看看babel官网 function toMemberExpression(id) { return id.split(".").map(name => _core.types.identifier(name)).reduce((object, property) => _core.types.memberExpression(object, property)); } 接下来到了transform转换过程。在JSXElement节点类型exit函数内触发： JSXElement: { exit(path, file) { let callExpr; // ...省略若干代码 // 生成最新节点 callExpr = buildCreateElementCall(path, file); // ...省略若干代码 // 替换原有节点 path.replaceWith(_core.types.inherits(callExpr, path.node)); } } function buildCreateElementCall(path, file) { const openingPath = path.get("openingElement"); // getTag(openingPath)---> returns h1节点 return call(file, "createElement", [getTag(openingPath), buildCreateElementOpeningElementAttributes(file, path, openingPath.get("attributes")), ..._core.types.react.buildChildren(path.node)]); } // _core.types.react.buildChildren 对应下述函数，生成elements数组, 见下图 // 其实就是将之前JSXElement里的JSXText JSXExpressionContainer信息提取出来 // types/lib/builders/react/buildChildren.js function buildChildren(node) { const elements = []; for (let i = 0; i < node.children.length; i++) { let child = node.children[i]; if ((0, _generated.isJSXText)(child)) { (0, _cleanJSXElementLiteralChild.default)(child, elements); continue; } if ((0, _generated.isJSXExpressionContainer)(child)) child = child.expression; if ((0, _generated.isJSXEmptyExpression)(child)) continue; elements.push(child); } return elements; } 最终生成的React.createElement节点信息，这里也增加了leadingComments前置注释信息：/#PURE/，来替换掉原有的节点信息。那么最终在Babel的generate环节，就会生成相应的JS代码：/#PURE/React.createElement("h1", null, "Hello, ", formatName(user), "!"); Babel generate生成代码环节，即针对不同的AST节点信息，采用相应的处理函数。比如通过node.type来获取节点类型program，获取到提前声明好的function program () { ... }处理函数。对于AST抽象语法树这样的数据接口，采取深度优先遍历。使用递归或者循环的方式。如果AST层级过深，那递归层次也会过深，可能栈溢出，所以可以加一个数组（作为栈）来记录接下来要遍历的 AST，这样就可以变成循环了。以下是Babel generator中的主要处理函数： print(node, parent) { if (!node) return; // 这里获取每种ast节点相应的处理方式 const printMethod = this[node.type]; // ... 省略代码 // 通过循环的方式，维护一个数组，进行处理 this._printStack.push(node); // ... 省略代码 this.withSource("start", loc, () => { printMethod.call(this, node, parent); }); // ... 省略代码 if (shouldPrintParens) this.token(")"); this._printStack.pop(); } Vue 这部分的解析过程是基于Vue 3.1.0-beta.7版本与React不同的是，Vue template的解析方式是自己内部实现的，在@packages/compiler-core中，提供了baseCompile、baseParse等核心compiler函数，在baseParse函数中，主要是通过特定字符来循环解析代码字符串，比如< ! / a-z等。 // baseCompile const ast = baseParse(template, options) export function baseParse( content: string, options: ParserOptions = {} ): RootNode { // 生成parse context上下文，主要内容{ options: {delimiters: ['{{', '}}']}, source: 'html string', originalSource: 'html string' } 后面解析html成ast，主要是操作context.source const context = createParserContext(content, options) // 记录初始位置 {line: 0, column:0, offset: 0} const start = getCursor(context) // 主要是parseChildren解析，在这个函数内，判断html string( context.source---> s)；返回的数据格式是[node {}, node...] // parseChildren内部声明了nodes = [];每解析完一个标签字符，就会nodes.push(node) // 1. s[0] 是 < // 1.1 s[1] 是!; 有三种情况：注释<!-- 文档<!DOCTYPE <![CDATA[；分别用parseComment parseBogusComment解析 // 1.2 s[1] 是 /: s[2] > 前进3个字符； s[2] a-z 前进3个字符 // 1.3 s[1] 是a-z 则表明是element标签，parseElement进行解析 // parseElement内会调用parseTag，利用正则匹配出tag，再次调用parseChildren 生成子节点，并把当前父节点作为ancestor传给 parseChildren,parseChildren 内部调用isEnd函数判断接下来的s字符串是否是父标签的结束标签。 // 2. s[0]是{{，parseInterpolation，生成动态标签 dynamic // 否则就是文本，调用parseText进行解析 return createRoot( parseChildren(context, TextModes.DATA, []), getSelection(context, start) ) } 在generate阶段，则Babel的设计思路差不多，通过递归的方式生成代码 // 1. 生成generate上下文，包括{code: '', helper() {}, push() {}, indent() {}, newline() {}} // 2. genFunctionPreamble push(`const _Vue = ${VueBinding}\n`) push(`const { ${staticHelpers} } = _Vue\n`) const functionName = ssr ? `ssrRender` : `render` const args = ssr ? ['_ctx', '_push', '_parent', '_attrs'] : ['_ctx', '_cache'] push(`function ${functionName}(${signature}) {`) // ... if (useWithBlock) { push(`with (_ctx) {`) indent() // function mode const declarations should be inside with block // also they should be renamed to avoid collision with user properties if (hasHelpers) { push( `const { ${ast.helpers .map(s => `${helperNameMap[s]}: _${helperNameMap[s]}`) .join(', ')} } = _Vue` ) push(`\n`) newline() } } // ... if (ast.codegenNode) { // genNode根据node.type判断不同类型: // genVNodeCall genText genExpression genInterpolation genComment genNode(ast.codegenNode, context) } else { push(`null`) } 在前端工程化很成熟的今天，我们用的很多工具都是依赖于AST抽象语法树进行解析和构建的。大体的思路都是parse、transform、generate三个阶段。

life.caoover 5 years

微信小程序分包实操

微信小程序分包实操背景：总包过太，代码首包超了2M。描述：将代码划分成不同的包，打开一个包中的某个页面，才加载这个包的代码。也可预先加载其他的包。为什么需要分包？一、小程序分包大小限制未分包情况：代码总包大小不超2M 分包情况：整个小程序所有分包大小不超过 20M 分包情况：单个分包/主包大小不能超过 2M 二、按需加载，可实现访问某些页面去触发加载分包（配置preloadRule）三、优化下载和启动时间。四、可有效分割多种业务、多个团队共同开发的情况。分包注意事项启动页 & TabBar 配置的路径必须放主包里。不同的分包间资源不能相用，但可引用主包中的。即：公共相关的基本都放主包，也会导致主包偏大。多个分包之间尽量互相隔离。虽然可以 require('../subPackageA/utils.js') 访问到分包实操 manifest.json 配置处开启分包 // manifest.json 开启分包 "mp-weixin": { "optimization": { "subPackages": true } } 按拆包规则配置路由注意事项：分包后的文件路径、图片路径，以及路由跳转路径都要做对应修改（尽量不改变原来路由） // pages.json 路由 { "pages": [{ "path": "pages/index/index", "style": {...} }], "subPackages": [{ "root": "subpage", "pages": [{ "path": "list/list", "style": { ...} }]， // "independent": true // 用于区分常规分包和独立分包一般不这么干 }], "preloadRule": { // 预加载 "pages/car-maintenance/home/index": { "network": "all", "packages": ["subpage"] } } } 常规分包和独立分包的区别：独立分包可独立于主包和其他分包运行。独立分包中不能定义 App，会造成无法预期的行为；同时独立分包中暂时不支持使用插件；拆包思想这里，可以按项目的业务逻辑、不同页面的使用频率、喜好规划来弄。这边目前是结合现状、线上页面统计访问频率、页面路由层级、以及页面重要程度来进行区分。低版本兼容由微信后台编译来处理旧版本客户端的兼容，后台会编译两份代码包，一份是分包后代码，另外一份是整包的兼容代码。新客户端用分包，老客户端还是用的整包，完整包会把各个 subpackage 里面的路径放到 pages 中。分包结果查看路径：开发者工具 --> 详情 ---> 基本信息 ---> 本地代码查看分包前：分包后：体验上，在跳分包页面路径会加载比较久，所以还是需配置 preloadRule 预加载。总结：提前做好拆包规划（无包袱），主次分明、包与包尽量互相隔离官方链接

319

life.caoover 5 years

app内刘海屏css适配

app内刘海屏css适配适配之前需要了解的几个点 1.安全区域安全区域指的是一个可视窗口范围，处于安全区域的内容不受圆角、刘海、底部黑条影响。适配的宗旨就是保证页面可视、可操作区域是在安全区域内。 2.viewport-fit iOS11 的新增特性，为了适配 iPhoneX +，对现有 viewport meta 标签的一个扩展，可设置三个值： contain: 可视窗口完全包含网页内容（左图） cover：网页内容完全覆盖可视窗口（右图） auto：默认值，跟 contain 表现一致适配刘海屏、底部黑条，head标签处须设置meta viewport-fit=cover ，这样对应的预定义css才会生效。 <meta name="viewport" content="width=device-width, user-scalable=no, initial-scale=1.0, maximum-scale=1.0, minimum-scale=1.0, viewport-fit=cover" /> 3.env() 和 constant() Webkit 的一个 CSS 函数，用于设定安全区域与边界的距离，有四个预定义的变量： safe-area-inset-left：安全区域距离左边边界距离 safe-area-inset-right：安全区域距离右边边界距离 safe-area-inset-top：安全区域距离顶部边界距离 safe-area-inset-bottom：安全区域距离底部边界距离通常竖屏情况：只需关注safe-area-inset-top、safe-area-inset-bottom，左右值为0。横屏情况: 就需要考虑左边边界、右边边界的值。横屏安全区域端内适配建议通常在端内会使用原生的头部，所以这里需提前关注隐藏自定义头&padding 距离自定义头原生头底部黑条距离，safe-area-inset-bottom .foot{ padding-bottom: calc(constant(safe-area-inset-bottom)); padding-bottom: calc(env(safe-area-inset-bottom)); // 原有基数情况 padding-bottom: 20px; padding-bottom: calc(20px(假设值) + constant(safe-area-inset-bottom)); padding-bottom: calc(20px(假设值) + env(safe-area-inset-bottom)); } Bug: 在端内，如果一开始渲染页面高度没有达到100%，那底部就会出现一个原生的安全区域，导致出现双层安全区域。双层区域 // fix: 去除原生的底部安全区域 html { min-height: 100vh; } body { min-height: 100vh; } 很多 Android 手机也会按照 iOS 的标准来实现安全区域，大部分 Android 手机上也能正常使用。

123

life.caoabout 2 hours

前端从VS Code换成了Cursor

前端从VS Code换成了Cursor 家人们谁懂啊，作为一个天天跟Vue3、TS、Element Plus打交道的业务前端，我之前一直觉得VS Code就是编辑器的天花板了——装了几十款插件，开了Copilot，快捷键背得滚瓜烂熟，觉得这辈子都不会换编辑器了。结果被同组的同事安利了Cursor，抱着“反正底层也是VS Code，试试也不亏”的心态用了两周，现在我的VS Code已经在电脑里吃灰了。这篇文章就跟大家聊聊，一个普通前端开发，到底怎么把Cursor用出「效率翻倍」的效果，全程都是我日常开发的真实用法，没有官方教程那种假大空的内容，看完就能直接上手。先跟不了解的同学唠两句：Cursor到底是个啥？说白了，Cursor就是一款AI原生的代码编辑器，最让我放心的一点是，它底层是基于VS Code构建的——这也是我敢直接换的核心原因：上手零成本。我之前在VS Code里用的Volar、ESLint、Prettier、主题插件，甚至连自定义的快捷键，全都能一键同步过来，前后10分钟就完成了迁移，完全没有换工具的阵痛期。它跟「VS Code+Copilot」最大的区别是：Copilot本质上只是个「代码补全插件」，只能在你敲代码的时候给你补两行；而Cursor的AI能力是嵌到编辑器骨子里的，你写代码的全流程，从需求拆解、代码生成、调试重构到上线前检查，它都能无缝接入，而不是只做个“补全工具”。前端开发最常用的5个场景，全是能直接抄的用法我不会给你讲一堆花里胡哨、日常根本用不上的功能，就说我每天上班必用的几个场景，每一个都能帮你少加半小时班。 1. 10秒生成业务组件，告别重复CV 前端开发80%的时间，都在写重复的业务组件：带校验的表单、自适应的卡片列表、详情页、二次确认弹窗… 之前我要么从老项目里CV过来改，要么对着组件库文档一行行写，光搭个架子半小时就没了。现在我只需要选中要写的文件，按 Ctrl/Cmd + K 唤起快速输入框，扔进去需求，直接生成能用的代码。给大家看我日常用的prompt模板，直接抄就行：帮我修改这段卡片列表的样式改成响应式布局：375px 以下一行 2 个，768px 以上一行 4 个，1200px 以上一行 6 个每个卡片加上 hover 上浮 + 阴影的过渡动画，时长 0.3s，要流畅不卡顿解决 Safari 浏览器里 flex 布局换行错乱的兼容问题加上移动端 1px 下边框，解决高清屏线条变粗的问题几秒钟就给你改好了，连兼容前缀都给你加上了，不用再去搜「Safari flex兼容问题」「移动端1px边框解决方案」了。 4. 接口联调+TS类型自动生成，不用再手动CV 前端联调接口，最烦的就是手动写TS类型——后端给了几十字段的swagger文档，要一个一个抄到interface里，写错一个字母就会出bug，费时又费力。用Cursor，直接把后端的接口文档、返回示例，甚至swagger地址扔进去，直接让它生成： `根据下面的接口返回数据，生成对应的 TypeScript interface，要求字段名和类型完全对应，每个字段加上中文注释 {"code": 200,"data": {"id": 1,"username": "test","phone": "13800138000","createTime": "2024-01-01 00:00:00","roleList": [{"id": 1, "roleName": "管理员"}]},"msg": "success"}` 甚至你可以让它直接帮你封装好axios请求函数，加上请求/响应拦截、错误处理、loading状态管理，连mock数据都能一起生成，联调效率直接拉满。 5. Debug神器，报错直接给你改好写代码最崩溃的，就是控制台报了一堆红，搜了半天也找不到问题在哪——比如Vue的响应式丢失、TS类型报错、跨域问题、打包构建失败… 之前我要把报错信息复制到搜索引擎，翻半天帖子才能找到解决方案，现在直接把报错信息+对应的代码，全选扔给Cursor，直接问：这段代码运行报了这个错，帮我找出问题的根本原因，直接给我修改后的完整代码，顺便告诉我为什么会出现这个问题，下次怎么避免它不仅会给你改好代码，还会给你讲清楚报错的根本原因，相当于一边写代码一边学东西，下次再遇到同样的问题，自己就会解决了。前端必记的3个核心快捷键，形成肌肉记忆超爽 Cursor的快捷键有很多，但我日常用的最多的就3个，完全覆盖了90%的开发场景，现在已经形成肌肉记忆了：快捷键核心作用我的高频使用场景 Ctrl/Cmd + K 快速唤起AI输入框，支持选中代码直接修改写业务组件、改样式、快速生成代码片段 Ctrl/Cmd + L 选中代码打开对话面板，针对这段代码持续对话梳理代码逻辑、排查bug、重构老代码 Ctrl/Cmd + I 在当前光标位置，直接插入AI生成的代码补全代码、写注释、加TS类型定义我踩过的4个坑，大家一定要避开用了两个多月，我也踩了不少坑，这里给大家提个醒，别跟我一样走弯路：不要完全依赖AI，核心逻辑一定要自己把控有一次我让AI帮我写一个复杂的列表无限滚动动画，生成的代码虽然能跑，但是在低端安卓机上疯狂掉帧，线上出了问题还是我自己背锅。AI生成的代码只能当参考，核心的性能、业务逻辑，一定要自己过一遍，逐行检查。公司敏感代码，一定要开本地模式如果是写公司的核心业务代码，一定要在设置里打开「本地模式」，关闭云端代码同步，避免代码泄露，这个是底线，千万别嫌麻烦。免费版够用，重度使用再开Pro 免费版每个月有50次GPT-4调用额度，还有无限的GPT-3.5调用，日常写业务用3.5完全够了，只有遇到复杂的重构、疑难bug排查再用4，个人开发免费版基本够用，不用一上来就开Pro。生成的代码一定要过一遍ESLint和Prettier AI生成的代码有时候格式会乱，甚至会有不符合你团队规范的写法，一定要用ESLint格式化一遍，不然提交代码的时候，真的会被同事骂。最后：到底值不值得从VS Code换到Cursor？很多人说，AI会替代前端开发，但我用了这么久，反而觉得它让我更值钱了。之前我要花60%的时间，写重复的表单、调样式、改bug、抄类型定义，这些没有技术含量的活，占了我大部分的工作时间。现在这些活，AI10分钟就能帮我干完，我能花更多的时间去研究用户体验、性能优化、前端架构设计，这些才是前端开发的核心竞争力。对于普通前端开发来说，Cursor不是一个「替代你的工具」，而是一个「帮你提效的搭档」。它的上手成本几乎为零，只要你会用VS Code，就能无缝切换，为什么不试试呢？

曹来福的技术小屋

如何使用Xcode调试web在iOS10.x.x兼容问题（含破解文件）

Web Components原生支持的组件化

Gridsome 四部曲之介绍 （一）

Gridsome 四部曲之起步 （二）

Gridsome 四部曲之基础 （三）

Gridsome 四部曲之处理数据GraphQL （四）

Virtual DOM和Virtual DOM库——Vue虚拟dom的借鉴

Snabbdom 基本使用——学习Vue Virtual DOM的最佳入门库

Snabbdom 源码解析与如何调试（一）

Snabbdom 源码解析与如何调试（二）

吐血整理react快速入门精华（一）

吐血整理react快速入门精华（二）

一行配置构建速度提升，Webpack5持久化缓存

低代码之拖拽排序实现思路-徒手开

如何更好的使用React中context

装饰器模式的实践——Decorator

WebP方案的探索与实践

web 端动画的实现和探索

库开发者需要了解的的 babel

异步调用的一致性问题—— useRequest

主流css置灰写法

原生 JavaScript 徒手开一个弹幕组件

React 中表单的规范和核心

自定义 hook 实现 React 状态管理

Hooks中使用MVC思想

React 异步场景和一致性

分支开发规范（可结合自己团队稍作修改）

生产发布SOP

Module Federation 在H5项目的实践

从bundle产物中分析webpack5 Module Federation

Tailwind CSS的实践和流程分析

H5实现pdf和excel在线预览

小程序优化首包大小—分包异步化

徒手开Webpack 5系

浅谈浏览器的剪切板 API 及其实践

怎样编写一条自定义 eslint 规则

从React DevTools中发掘 ReactDOM 中的一些隐藏特性

代码重构之理论和实践

React 18 新增的几种hooks

图片处理在前端项目中的实践，包含涂抹、裁切、打码等

微前端实践和总结

关于UserAgent

浅谈AST

Proxy配合使用Reflect

关于如何提高效能的陷阱

有了vite，umi还香吗？

从实践中总结的Git 操作

手把手教你Monorepo 组件库搭建 —— 第一部分

手把手教你Monorepo 组件库搭建 —— 第二部分

手把手教你Monorepo 组件库搭建 —— 第三部分

前端单元测试和集成测试

带你徒手开Webpack实现原理（1）——AST和Loader

带你徒手开Webpack实现原理（2）—— Plugin

带你徒手开Webpack实现原理（3）—— Mini 型的 Webpack

从刚好铺满一屏的css需求来看移动端适配

潜聊JavaScript 策略模式

JavaScript中的 发布-订阅模式

JSX、Template如何被解析的？

微信小程序分包实操

app内刘海屏css适配

前端从VS Code换成了Cursor

Gridsome 四部曲之介绍（一）

Gridsome 四部曲之起步（二）

Gridsome 四部曲之基础（三）

JavaScript中的发布-订阅模式