做者简介:nekron 蚂蚁金服·数据体验技术团队javascript
将跨页面通信类比计算机进程间的通信,其实方法无外乎那么几种,而web领域能够实现的技术方案主要是相似于如下两种原理:html
因为第二种原理更利于解耦业务逻辑,具体的实现方案比较多样。如下是具体的实现方案,简单介绍下,权当科普:前端
父页面经过window.open(url, name)
方式打开的子页面能够获取句柄,而后经过postMessage完成通信需求。java
// parent.html
const childPage = window.open('child.html', 'child')
childPage.onload = () => {
childPage.postMessage('hello', location.origin)
}
// child.html
window.onmessage = evt => {
// evt.data
}
复制代码
window.open
的第二个name参数时,再次调用window.open('****', 'child')
会使以前已经打开的同name子页面刷新window.open
会被浏览器阻止,不过能够经过句柄设置子页面的url便可实现相似效果// 首先先开一个空白页
const tab = window.open('about:blank')
// 请求完成以后设置空白页的url
fetch(/* ajax */).then(() => {
tab.location.href = '****'
})
复制代码
缺点是只能与本身打开的页面完成通信,应用面相对较窄;但优势是在跨域场景中依然可使用该方案。git
设置共享区域的storage,storage会触发storage事件github
// A.html
localStorage.setItem('message', 'hello')
// B.html
window.onstorage = evt => {
// evt.key, evt.oldValue, evt.newValue
}
复制代码
API简单直观,兼容性好,除了跨域场景下须要配合其余方案,无其余缺点web
和localStorage
方案基本一致,额外须要初始化ajax
// A.html
const channel = new BroadcastChannel('tabs')
channel.onmessage = evt => {
// evt.data
}
// B.html
const channel = new BroadcastChannel('tabs')
channel.postMessage('hello')
复制代码
和localStorage
方案没特别区别,都是同域、API简单,BroadcastChannel
方案兼容性差些(chrome > 58),但比localStorage
方案生命周期短(不会持久化),相对干净些。chrome
SharedWorker
自己并非为了解决通信需求的,它的设计初衷应该是相似总控,将一些通用逻辑放在SharedWorker中处理。不过由于也能实现通信,因此一并写下:express
// A.html
var sharedworker = new SharedWorker('worker.js')
sharedworker.port.start()
sharedworker.port.onmessage = evt => {
// evt.data
}
// B.html
var sharedworker = new SharedWorker('worker.js')
sharedworker.port.start()
sharedworker.port.postMessage('hello')
// worker.js
const ports = []
onconnect = e => {
const port = e.ports[0]
ports.push(port)
port.onmessage = evt => {
ports.filter(v => v!== port) // 此处为了贴近其余方案的实现,剔除本身
.forEach(p => p.postMessage(evt.data))
}
}
复制代码
相较于其余方案没有优点,此外,API复杂并且调试不方便。
一个古老的方案,有点localStorage
的降级兼容版,我也是整理本文的时候才发现的,思路就是往document.cookie
写入值,因为cookie的改变没有事件通知,因此只能采起轮询脏检查来实现业务逻辑。
方案比较丑陋,势必被淘汰的方案,贴一下原版思路地址,我就不写demo了。
communication between browser windows (and tabs too) using cookies
相较于其余方案没有存在优点的地方,只能同域使用,并且污染cookie之后还额外增长AJAX的请求头内容。
以前的方案都是前端自行实现,势必受到浏览器限制,好比没法作到跨浏览器的消息通信,好比大部分方案都没法实现跨域通信(须要增长额外的postMessage逻辑才能实现)。经过借助服务端,还有不少加强方案,也一并说下。
后端无开发量,前端按期保存,在tab被激活时从新获取保存的数据,能够经过校验hash之类的标记位来提高检查性能。
window.onvisibilitychange = () => {
if (document.visibilityState === 'visible') {
// AJAX
}
}
复制代码
项目规模小型的时候能够采起这类方案,后端自行维护链接,以及后续的推送行为。
// 前端
const es = new EventSource('/notification')
es.onmessage = evt => {
// evt.data
}
es.addEventListener('close', () => {
es.close()
}, false)
// 后端,express为例
const clients = []
app.get('/notification', (req, res) => {
res.setHeader('Content-Type', 'text/event-stream')
clients.push(res)
req.on('aborted', () => {
// 清理clients
})
})
app.get('/update', (req, res) => {
// 广播客户端新的数据
clients.forEach(client => {
client.write('data:hello\n\n')
setTimeout(() => {
client.write('event:close\ndata:close\n\n')
}, 500)
})
res.status(200).end()
})
复制代码
socket.io
、sockjs
例子比较多,略
项目规模大型时,须要消息队列集群长时间维护长连接,在须要的时候进行广播。
提供该类服务的云服务商不少,或者寻找一些开源方案自建。
例如MQTT协议方案(阿里云就有提供),web客户端本质上也是websocket,须要集群同时支持ws和mqtt协议,示例以下:
// 前端
// 客户端使用开源的Paho
// port会和mqtt协议通道不一样
const client = new Paho.MQTT.Client(host, port, 'clientId')
client.onMessageArrived = message => {
// message. payloadString
}
client.connect({
onSuccess: () => {
client.subscribe('notification')
}
})
// 抑或,借助flash(虽然快要被淘汰了)进行mqtt协议链接并订阅相应的频道,flash再经过回调抛出消息
// 后端
// 根据服务商提供的Api接口调用频道广播接口
复制代码
原文地址: github.com/ProtoTeam/b…