我们在日常工作和生活中经常会使用到各种各样的 Chrome 扩展程序,比如 1Password 能自动帮你填充密码,Adblock 能帮你拦截广告,又或者是开发时经常会使用的 React Developer Tools,Redux DevTools 等等。这些扩展程序对效率的提升是巨大的。在日常开发过程中,我们也可以尝试开发自己的扩展程序,来辅助提升团队的开发体验和效率。本文首先会展示一个实际开发扩展程序的例子,从而让读者体会到当前开发时存在的问题,并基于此提出解决方案。如果你已经对如何开发一个扩展程序很熟悉了,那么直接看下文中【新的开发方式】部分,或者直接浏览对应的框架—— browser-extension-kit(https://github.com/alibaba/browser-extension-kit)即可。
假设我们要做一个可以重定向请求的扩展程序(类似 XSwitch),可以将当前页面的某个请求重定向到用户输入的地址,比如将某个环境下当前页面的 js 重定向到本地 webpack-dev-server 提供的 js,这样就可以实现线上调试功能了。
为了实现这个功能,我们首先需要一个页面能够让用户输入重定向前后对应的 url,这个页面会在用户点击该扩展程序的 icon 时展开,在 Chrome 官方文档中称为 popup。同时,实现具体重定向逻辑是在一个叫 background 的地方。根据官方指南,任何一个扩展程序都必须有一个 background,这个 background 存在于扩展程序的整个生命周期。通常情况下,你应该把所有核心业务逻辑和状态定义在 background 中。
在扩展程序的世界中,background 和 popup 都是完全独立的执行环境,这意味着彼此之间无法直接获取对方定义的变量、函数等。而用户输入的参数,需要从 popup 传递到 background 中,在扩展程序的场景下,官方提供了基于消息的机制来完成数据的流转。
首先,我们在 popup 中处理用户输入:
// popup.js
import React from 'react';
// 在这里向 background 发起连接,之后会通过这个 port 来监听或者发送消息
const port = chrome.runtime.connect();
export const App = () => {
return (
<>
<div>
原始 URL:<input onChange={e => port.postMessage({ originalUrl: e.target.value })} />
</div>
<div>
新 URL:<input onChange={e => port.postMessage({ newUrl: e.target.value })} />
</div>
</>
);
};
而在 background 中,我们需要等待连接建立,之后即可监听消息,拿到对应的数据,并且处理重定向逻辑:
// background.js
let originalUrl = '';
let newUrl = '';
chrome.runtime.onConnect.addListener(port => {
port.onMessage.addListener(message => {
if (message.originalUrl) {
originalUrl = message.originalUrl;
} else if (message.newUrl) {
newUrl = message.newUrl;
}
});
});
chrome.webRequest.onBeforeRequest.addListener(request => {
if (!originalUrl || !newUrl || request.url !== originalUrl) {
return;
}
return { redirectUrl: newUrl };
}, {}, ['blocking'])
一个最简单的例子就写好了。当然,要让这个例子实际能跑起来,还需要提供一个 manifest.json 给浏览器,在这个文件中声明该扩展程序的元信息,在此略过。如果你有兴趣,还可以看看官方指南(https://developer.chrome.com/docs/extensions/mv3/getstarted/),浏览器提供了丰富的 API,能够帮助你实现任何你想做的事。
虽然这个例子很简单,但是可以看到,如果要开发一个扩展程序,少不了要和消息机制打交道。对一个有实际业务逻辑的扩展程序来说,发送消息、接受消息是一个极高频的场景。
对于一个功能完整的扩展程序来说,显然不会像刚才的例子那样简单。通常来说,一个扩展程序会涉及到多个执行环境(如 content-script、 popup 等,这些都是 Chrome 提供的彼此互相独立的执行环境),同时可能提供多个功能,而 background 负责全局的状态管理和逻辑串联。在这个假设下,我们很自然的构造出如下的目录结构:
src
background
module1
index.ts
...
module2
index.ts
...
index.ts
popup
module1
index.ts
...
module2
index.ts
...
index.ts
content-script
...
首先,我们应该会在background/index.ts
里初始化我们的 background 功能,在这里开始监听全局所有的消息,再根据消息的某个标识符(这里是port.name
)分发到对应的模块中,由这些模块处理具体的业务逻辑,整个流程和 Redux 很像:
这里使用了 rxjs,很适合处理类似消息这样的场景,当然不用也行,这不是本文的重点
import { fromEventPattern, merge } from 'rxjs';
import { module1Processer, observable1 } from './module1';
import { module2Processer, observable2 } from './module2';
// 为了保存不同执行环境发来的消息,考虑到每个 port 生成时机、消息流向等不同,不得不保存外部变量
let devtoolPort: chrome.runtime.Port | undefined;
let contentScript: chrome.runtime.Port | undefined;
let pageScriptPort: chrome.runtime.Port | undefined;
// 以下 2 个 fromEventPattern,分别处理内部、外部消息
fromEventPattern<chrome.runtime.Port>(
handler => chrome.runtime.onConnect.addListener(handler),
handler => chrome.runtime.onConnect.removeListener(handler)
).subscribe(port => {
if (port.name === 'devtool') {
devtoolPort = port;
} else {
//...
}
port.onMessage.addListener(message => {
switch (message.type) {
// 分发消息到具体的 module
case module1: { module1Processer() }
case module2: { module2Processer() }
}
});
})
fromEventPattern<chrome.runtime.Port>(
handler => chrome.runtime.onConnectExternal.addListener(handler),
handler => chrome.runtime.onConnectExternal.removeListener(handler)
).subscribe(port => {
if (port.name === 'devtool') {
devtoolPort = port;
} else {
//...
}
//...
})
// 有些功能需要整合多个 module 内的数据,放在这里处理
merge(observable1, observable1).pipe(...).subscribe(...)
而在 UI 部分(如 popup )中,不出意外肯定需要调用 background 的能力,并且监听来自 background 的消息。如果使用 React 来写 UI 的话,我们可能会将这部分功能包装到顶层 Context 里,向下传递:
import { createContext, useState, useRef } from 'react';
// 手动建立连接
const port = chrome.runtime.connect({ name: BACKGROUND_MESSAGE_NAME });
const defaultStore: Store = {
// 功能 1 的 state
module1: {...},
// 功能 2 的 state
module2: {...},
// 类似 Redux 中的 dispatch,用来传递消息,发送事件
dispatch: {
// 功能 1 的 action
module1: (payload) => {
port.postMessage({ type: MessageType.emit, payload: { ...payload, domain: 'module1' } });
},
// ...
}
};
export const Context = createContext<Store>(defaultStore);
const ContextProvider = () => {
const [store, setStore] = useState(defaultStore);
const storeRef = useRef(defaultStore);
useEffect(() => {
port.onMessage.addListener(msg => {
// 手动监听事件,根据不同的事件更新不同的 state
switch (msg.type) {
case MessageType.storeChanged: {
storeRef.current = {
...storeRef.current,
[msg.payload.domain]: msg.payload.store,
};
setStore(storeRef.current);
break;
}
default:
break;
}
});
// eslint-disable-next-line react-hooks/exhaustive-deps
}, []);
return (
<Context.Provider value={store}>
<App />
</Context.Provider>
);
};
export default ContextProvider;
可以看到,在这种代码组织方式下,一旦功能变的复杂起来,会变的很难维护。而每当新增一个功能模块时,都少不了一大堆模板代码(监听消息并派发、UI 中初始化对应 store 等)。类比一下的话,我们在写原生 Redux 时不爽的地方,就是这里会感到不爽的地方。
通过刚才的例子,我们可以看出,在开发 Chrome 扩展程序时,处理不同执行环境下的消息流转是一件很麻烦的事。事实上,执行环境还有很多:
这些环境之间互相隔离,通信只能依靠 message。在实际开发过程中,我们遇到了 2 类问题:
框架能力缺失:社区中没有针对开发扩展程序的最佳实践,自然也就没有对应的框架能力,导致每个项目、模块之间重复建设或者逻辑混乱,例如如下这些常用模块或功能:
监控
埋点
日志
鉴权、用户信息
消息机制
实际经验缺失:由于不是经常会开发到的场景,在初次上手时踩坑是在所难免的,例如:
content-script 插入带 iframe 的页面时执行环境错乱(this 指向问题,意外创建多实例等)
Chrome API 在不同执行环境下可用性差异大
这里需要特别强调一下消息机制的问题,这是目前开发扩展程序面临的最大的问题。Chrome 扩展程序本身提供了基于postMessage的消息传递机制,在实际开发中遇到如下问题:
window.postMessage
扩展程序中不同执行环境相互隔离这一点无法改变,但是,在每个执行环境中,开发中应该专注于自己的逻辑,不用关心事件注册、逻辑派发、公共方法调用等这些通用能力,这些东西都应该交给框架去做。
总体上来说,新的方式下,业务逻辑通过继承特定的类,获取到父类上的公共方法,这些公共方法中包装好了关于消息、日志等的逻辑,可供直接使用。基于这个想法,我们可以设计出新的编写形式:
import rxjs from 'rxjs';
import { Background } from 'browser-extension-kit/background';
import { subject, observable } from 'browser-extension-kit';
export default class MyBackground extends Background {
constructor() {
super();
// 对 myObservable1$ 额外的处理逻辑
this.myObservable1$.subscribe(data => {
// do something with data
});
// 订阅消息
this.on('messageID', message => {
// ...
});
}
// 接受外界传来的 id 为 'uniqueID' 的消息,并且自动转化为 mySubject 的下一个值
@subject('uniqueID') private mySubject = new rxjs.Subject<number>();
// 通过 @observable.popup 来声明当 myObservable1$ 发出一个值时,自动通过消息传递给 popup
// 这个消息的默认 id 为 'MyBackground::myObservable1$',可自定义
@observable.popup private myObservable1$ = rxjs.from(...).pipe(
rxjs.shareReplay(1)
);
// 当多个环境都需要订阅这个消息时,可以使用 @observable(['background', 'popup'])
@observable(['background', 'popup']) private myObservable2$ = rxjs.concat(
rxjs.from(...),
this.mySubject
).pipe(
rxjs.shareReplay(1)
);
}
在 popup、devtools 等环境中,通常都是一个 React 组件,这种情况下,框架提供了相应的 hooks 来帮助实现逻辑:
import React from 'react';
import { useMessage, usePostMessage } from 'browser-extension-kit/popup';
const App = () => {
const active = useMessage('MyBackground::active$', null);
const port = usePostMessage();
const toggleActive = useCallback(() => {
port.background('MyBackground::active', !active);
}, [port]);
return (
<div>
active: {active}
<button onClick={toggleActive}>click me</button>
</div>
);
};
export default App;
可以猜到,如果要使用上述新的开发方式,核心是要在各个基类中内置处理消息的逻辑,background 负责所有消息的接受和转发,这一点依然不变,对外只暴露处理好的消息即可:
事实上,在这种方案下,所有的消息都会由 background 中转一下,在一定程度上造成了性能损失,这也算是在简洁和性能之间的一种取舍。而对于 devtools 和 popup 这 2 个 UI 的部分,目前只考虑了在 React 下的场景。此外,虽然监控、埋点、鉴权等也是较为通用的功能,但是不同的业务也存在着不同的诉求,所以这一部分无法集成到框架中,需要业务自行实现。如果符合你的口味,可以直接安装体验一下:
npm i browser-extension-kit -S
// or
yarn add browser-extension-kit
更多使用方式和 API 可在 https://github.com/alibaba/browser-extension-kit 查看,如果感兴趣,欢迎一起交流。
Copyright© 2013-2020
All Rights Reserved 京ICP备2023019179号-8