无需申请自动送彩金68_白菜送彩金网站大全[无需申请秒送彩金]
做最好的网站
来自 无需申请自动 2019-10-19 08:43 的文章
当前位置: 无需申请自动送彩金68 > 无需申请自动 > 正文

复杂单页应用的数据层设计,入门教程

渐进式Web应用(PWA)入门教程(上)

2018/05/23 · 基础技术 · PWA

原文出处: Craig Buckler   译文出处:葡萄城控件   

最近关于渐进式Web应用有好多讨论,有一些人还在质疑渐进式Web应用是否就是移动端未来。

但在这篇文章中我并不会将渐进式APP和原生的APP进行比较,但有一点是可以肯定的,这两种APP的目标都是使用户体验变得更好。

移动端Web应用有很多优秀的概念让人应接不暇,但好在编写一个渐进式Web应用不是一个很困难的事情。在这篇文章里将向你介绍如何把一个普通的网站转换成渐进式Web应用。你可以按照这篇文章一步一步地做,做完之后你的网站将可以实现离线访问,并且可以在桌面上创建该网站的图标。那么下面即将开始入门教程。

Service Worker初体验

2016/01/06 · JavaScript · Service Worker

原文出处: AlloyTeam   

在2014年,W3C公布了service worker的草案,service worker提供了很多新的能力,使得web app拥有与native app相同的离线体验、消息推送体验。
service worker是一段脚本,与web worker一样,也是在后台运行。作为一个独立的线程,运行环境与普通脚本不同,所以不能直接参与web交互行为。native app可以做到离线使用、消息推送、后台自动更新,service worker的出现是正是为了使得web app也可以具有类似的能力。

 

service worker可以:

  1. 后台消息传递
  2. 网络代理,转发请求,伪造响应
  3. 离线缓存
  4. 消息推送
  5.  … …

本文以资源缓存为例,说明一下service worker是如何工作的。

复杂单页应用的数据层设计

2017/01/11 · JavaScript · 单页应用

原文出处: 徐飞   

很多人看到这个标题的时候,会产生一些怀疑:

什么是“数据层”?前端需要数据层吗?

可以说,绝大部分场景下,前端是不需要数据层的,如果业务场景出现了一些特殊的需求,尤其是为了无刷新,很可能会催生这方面的需要。

我们来看几个场景,再结合场景所产生的一些诉求,探讨可行的实现方式。

什么是渐进式Web应用?

渐进式Web应用是一种全新的Web技术,让Web应用和原生APP的体验相近或一致。

渐进式Web应用它可以横跨Web技术及Native APP开发的解决方案,对于开发者的优势如下:

  1. 你只需要关心W3C的Web标准,不用关心各种Native APP的代码。
  2. 用户可以在安装应用之前先试用。
  3. 在渐进式Web应用中,你不需要使用各种应用商店来分发应用,也不用关心应用发布时奇怪的审核标准以及应用内购的平台抽成。另外,应用程序更新是自动进行的,无需用户交互,所以整体的使用体验对于用户来讲更为的平滑。
  4. 渐进式Web应用的“安装”过程很快,只需要在主屏幕上添加一个图标即可。
  5. 渐进式Web应用启动时可以显示一个好看的启动画面。
  6. 你可以在渐进式Web应用中提供具有全屏体验的应用。
  7. 通过系统通知等形式提高用户的粘性。
  8. 渐进式Web应用将会在本地缓存必要的文件,所以渐进式Web应用会比普通的Web应用的性能更好。
  9. 轻量级安装——你只需要缓存几百KB的数据即可。
  10. 所有的数据传输必须使用安全的HTTPS连接
  11. 渐进式Web应用可以离线缓存数据,并且会在重新连接互联网时重新同步数据。

生命周期

先来看一下一个service worker的运行周期

图片 1
上图是service worker生命周期,出处

图中可以看到,一个service worker要经历以下过程:

  1.  安装

2.  激活,激活成功之后,打开chrome://inspect/#service-workers可以查看到当前运行的service worker

图片 2

  1. 监听fetch和message事件,下面两种事件会进行简要描述

  2. 销毁,是否销毁由浏览器决定,如果一个service worker长期不使用或者机器内存有限,则可能会销毁这个worker

视图间的数据共享

所谓共享,指的是:

同一份数据被多处视图使用,并且要保持一定程度的同步。

如果一个业务场景中,不存在视图之间的数据复用,可以考虑使用端到端组件。

什么是端到端组件呢?

我们看一个示例,在很多地方都会碰到选择城市、地区的组件。这个组件对外的接口其实很简单,就是选中的项。但这时候我们会有一个问题:

这个组件需要的省市区域数据,是由这个组件自己去查询,还是使用这个组件的业务去查好了传给这个组件?

两者当然是各有利弊的,前一种,它把查询逻辑封装在自己内部,对使用者更加有利,调用方只需这么写:

XHTML

<RegionSelector selected=“callback(region)”></RegionSelector>

1
<RegionSelector selected=“callback(region)”></RegionSelector>

外部只需实现一个响应取值事件的东西就可以了,用起来非常简便。这样的一个组件,就被称为端到端组件,因为它独自打通了从视图到后端的整个通道。

这么看来,端到端组件非常美好,因为它对使用者太便利了,我们简直应当拥抱它,放弃其他所有。

端到端组件示意图:

A | B | C --------- Server

1
2
3
A | B | C
---------
Server

可惜并非如此,选择哪种组件实现方式,是要看业务场景的。如果在一个高度集成的视图中,刚才这个组件同时出现了多次,就有些尴尬了。

尴尬的地方在哪里呢?首先是同样的查询请求被触发了多次,造成了冗余请求,因为这些组件互相不知道对方的存在,当然有几个就会查几份数据。这其实是个小事,但如果同时还存在修改这些数据的组件,就麻烦了。

比如说:在选择某个实体的时候,发现之前漏了配置,于是点击“立刻配置”,新增了一条,然后回来继续原流程。

例如,买东西填地址的时候,发现想要的地址不在列表中,于是点击弹出新增,在不打断原流程的情况下,插入了新数据,并且可以选择。

这个地方的麻烦之处在于:

组件A的多个实例都是纯查询的,查询的是ModelA这样的数据,而组件B对ModelA作修改,它当然可以把自己的那块界面更新到最新数据,但是这么多A的实例怎么办,它们里面都是老数据,谁来更新它们,怎么更新?

这个问题为什么很值得说呢,因为如果没有一个良好的数据层抽象,你要做这个事情,一个业务上的选择和会有两个技术上的选择:

  • 引导用户自己刷新界面
  • 在新增完成的地方,写死一段逻辑,往查询组件中加数据
  • 发一个自定义业务事件,让查询组件自己响应这个事件,更新数据

这三者都有缺点:

  • 引导用户刷新界面这个,在技术上是比较偷懒的,可能体验未必好。
  • 写死逻辑这个,倒置了依赖顺序,导致代码产生了反向耦合,以后再来几个要更新的地方,这里代码改得会很痛苦,而且,我一个配置的地方,为什么要管你后续增加的那些查询界面?
  • 自定义业务事件这个,耦合是减少了,却让查询组件自己的逻辑膨胀了不少,如果要监听多种消息,并且合并数据,可能这里更复杂,能否有一种比较简化的方式?

所以,从这个角度看,我们需要一层东西,垫在整个组件层下方,这一层需要能够把查询和更新做好抽象,并且让视图组件使用起来尽可能简单。

另外,如果多个视图组件之间的数据存在时序关系,不提取出来整体作控制的话,也很难去维护这样的代码。

添加了数据层之后的整体关系如图:

A | B | C ------------ 前端的数据层 ------------ Server

1
2
3
4
5
A | B | C
------------
前端的数据层
------------
  Server

那么,视图访问数据层的接口会是什么样?

我们考虑耦合的问题。如果要减少耦合,很必然的就是这么一种形式:

  • 变更的数据产生某种消息
  • 使用者订阅这个消息,做一些后续处理

因此,数据层应当尽可能对外提供类似订阅方式的接口。

渐进式Web应用发展的现状

渐进式Web应用才刚刚开始发展,但实际上在国内,有些网站已经实际开始PWA的实践了,例如:微博、豆瓣、淘宝等平台。可能这时候聪明的你可能就会产生疑问,那这个PWA不就是和微信小程序一样吗,对是这样,二者的目的是一致的,就是在移动端为用户提供足够轻量且与原生应用使用体验相近的“轻”应用。

但就目前来讲,PWA是Google主推的一项技术标准,FireFox,Chrome以及一些基于Blink的浏览器已经支持渐进式Web应用了,Edge上对渐进式Web应用的支持还在开发。Apple公司也表示会考虑在自己Safari支持PWA。然而这项功能已经进入了WebKit内核的五年计划中。长期来看,对浏览器兼容性的支持方面应该已经不算太大问题了。况且在现阶段,在不支持渐进式Web应用的浏览器中,你的应用也只是无法使用渐进式Web应用的离线功能而已,除此之外的功能均可以正常使用。

而在微信这边,凭借庞大的用户基数和体量能否与PWA分庭抗礼乃至笑到最后目前还不得而知。

fetch事件

在页面发起http请求时,service worker可以通过fetch事件拦截请求,并且给出自己的响应。
w3c提供了一个新的fetch api,用于取代XMLHttpRequest,与XMLHttpRequest最大不同有两点:

1. fetch()方法返回的是Promise对象,通过then方法进行连续调用,减少嵌套。ES6的Promise在成为标准之后,会越来越方便开发人员。

2. 提供了Request、Response对象,如果做过后端开发,对Request、Response应该比较熟悉。前端要发起请求可以通过url发起,也可以使用Request对象发起,而且Request可以复用。但是Response用在哪里呢?在service worker出现之前,前端确实不会自己给自己发消息,但是有了service worker,就可以在拦截请求之后根据需要发回自己的响应,对页面而言,这个普通的请求结果并没有区别,这是Response的一处应用。

下面是在中,作者利用fetch api通过fliker的公开api获取图片的例子,注释中详细解释了每一步的作用:

JavaScript

/* 由于是get请求,直接把参数作为query string传递了 */ var URL = ''; function fetchDemo() { // fetch(url, option)支持两个参数,option中可以设置header、body、method信息 fetch(URL).then(function(response) { // 通过promise 对象获得相应内容,并且将响应内容按照json格式转成对象,json()方法调用之后返回的依然是promise对象 // 也可以把内容转化成arraybuffer、blob对象 return response.json(); }).then(function(json) { // 渲染页面 insertPhotos(json); }); } fetchDemo();

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
/* 由于是get请求,直接把参数作为query string传递了 */
var URL = 'https://api.flickr.com/services/rest/?method=flickr.photos.search&api_key=your_api_key&format=json&nojsoncallback=1&tags=penguins';
 
function fetchDemo() {
  // fetch(url, option)支持两个参数,option中可以设置header、body、method信息
  fetch(URL).then(function(response) {
    // 通过promise 对象获得相应内容,并且将响应内容按照json格式转成对象,json()方法调用之后返回的依然是promise对象
    // 也可以把内容转化成arraybuffer、blob对象
    return response.json();
  }).then(function(json) {
    // 渲染页面
    insertPhotos(json);
  });
}
 
fetchDemo();

fetch api与XMLHttpRequest相比,更加简洁,并且提供的功能更全面,资源获取方式比ajax更优雅。兼容性方面:chrome 42开始支持,对于旧浏览器,可以通过官方维护的polyfill支持。

服务端推送

如果要引入服务端推送,怎么调整?

考虑一个典型场景,WebIM,如果要在浏览器中实现这么一个东西,通常会引入WebSocket作更新的推送。

对于一个聊天窗口而言,它的数据有几个来源:

  • 初始查询
  • 本机发起的更新(发送一条聊天数据)
  • 其他人发起的更新,由WebSocket推送过来
视图展示的数据 := 初始查询的数据   本机发起的更新   推送的更新

<table>
<colgroup>
<col style="width: 50%" />
<col style="width: 50%" />
</colgroup>
<tbody>
<tr class="odd">
<td><div class="crayon-nums-content" style="font-size: 13px !important; line-height: 15px !important;">
<div class="crayon-num" data-line="crayon-5b8f4b62cb7b7061328078-1">
1
</div>
</div></td>
<td><div class="crayon-pre" style="font-size: 13px !important; line-height: 15px !important; -moz-tab-size:4; -o-tab-size:4; -webkit-tab-size:4; tab-size:4;">
<div id="crayon-5b8f4b62cb7b7061328078-1" class="crayon-line">
视图展示的数据 := 初始查询的数据   本机发起的更新   推送的更新
</div>
</div></td>
</tr>
</tbody>
</table>

这里,至少有两种编程方式。

查询数据的时候,我们使用类似Promise的方式:

JavaScript

getListData().then(data => { // 处理数据 })

1
2
3
getListData().then(data => {
  // 处理数据
})

而响应WebSocket的时候,用类似事件响应的方式:

JavaScript

ws.on(‘data’, data => { // 处理数据 })

1
2
3
ws.on(‘data’, data => {
  // 处理数据
})

这意味着,如果没有比较好的统一,视图组件里至少需要通过这两种方式来处理数据,添加到列表中。

如果这个场景再跟上一节提到的多视图共享结合起来,就更复杂了,可能很多视图里都要同时写这两种处理。

所以,从这个角度看,我们需要有一层东西,能够把拉取和推送统一封装起来,屏蔽它们的差异。

示例代码

大多数教程都讲述的是如何在Chrome上从零开始制作一个类似原生界面的应用。然而在这篇教程中,我们并不打算做一个单页面应用程序,所以在这我们也不必了解诸如Material Design等知识。那么下面我们就直接看示例吧。

你可以从GitHub中获取本教程对应的示例代码。

本示例中提供了一个有四个网页的网站,一个CSS文件和一个JavaScript文件。这个网站可以在所有的现代浏览器上正常工作(IE10 )。如果你的浏览器支持渐进式Web应用,用户可以在离线状态下将会直接访问缓存中的页面。

要想运行此示例,请确保你已经安装了Node.js。并请打开命令行,使用以下命令来运行该示例:

node ./server.js [port]

1
node ./server.js [port]

以上命令中,[port]是可选部分,默认为8888。使用 Ctrl C 即可停止Web服务器。

打开基于Blink内核的浏览器(Opera,Vivaldi,Chrome),然后在地址栏中输入 或者 Cmd/Ctrl Shift I)来查看控制台信息。

图片 3图片 4

查看首页,也可以在页面上点击一下,然后使用以下方法进入离线模式:

选中Network标签或者Application -> Service Workers 标签下的“离线”选项。重新访问之前访问过的网页,之前网页仍然会加载:

图片 5图片 6

message事件

页面和serviceWorker之间可以通过posetMessage()方法发送消息,发送的消息可以通过message事件接收到。

这是一个双向的过程,页面可以发消息给service worker,service worker也可以发送消息给页面,由于这个特性,可以将service worker作为中间纽带,使得一个域名或者子域名下的多个页面可以自由通信。

这里是一个小的页面之间通信demo

缓存的使用

如果说我们的业务里,有一些数据是通过WebSocket把更新都同步过来,这些数据在前端就始终是可信的,在后续使用的时候,可以作一些复用。

比如说:

在一个项目中,项目所有成员都已经查询过,数据全在本地,而且变更有WebSocket推送来保证。这时候如果要新建一条任务,想要从项目成员中指派任务的执行人员,可以不必再发起查询,而是直接用之前的数据,这样选择界面就可以更流畅地出现。

这时候,从视图角度看,它需要解决一个问题:

  • 如果要获取的数据未有缓存,它需要产生一个请求,这个调用过程就是异步的
  • 如果要获取的数据已有缓存,它可以直接从缓存中返回,这个调用过程就是同步的

如果我们有一个数据层,我们至少期望它能够把同步和异步的差异屏蔽掉,否则要使用两种代码来调用。通常,我们是使用Promise来做这种差异封装的:

JavaScript

function getDataP() : Promise<T> { if (data) { return Promise.resolve(data) } else { return fetch(url) } }

1
2
3
4
5
6
7
function getDataP() : Promise<T> {
  if (data) {
    return Promise.resolve(data)
  } else {
    return fetch(url)
  }
}

这样,使用者可以用相同的编程方式去获取数据,无需关心内部的差异。

连接移动端安装

除了在PC浏览器访问外,你也可以在移动设备上访问该示例。使用USB线缆将你的移动设备连接到电脑上,然后从右上角三个点菜单中打开More tools – Remote devices标签

图片 7图片 8

点击左侧的Settings菜单,然后添加一条端口映射(Port Forwarding)的规则,将8888映射为localhost:8888,现在你可以直接在手机打开Chrome然后访问http://localhost:8888 。

你可以使用浏览器的“添加到主屏幕”功能将当前网页添加到主屏幕,在你访问了几个页面之后,浏览器会将这个Web应用“安装”到你的设备上。浏览几个页面,关闭Chrome并将设备与电脑断开连接,点击桌面上生成的图标,你会看到一个Splash页面,并且你可以继续浏览之前浏览过的页面。

图片 9图片 10

利用service workder缓存文件

下面介绍一个利用service worker缓存离线文件的例子
准备index.js,用于注册service-worker

JavaScript

if (navigator.serviceWorker) { navigator.serviceWorker.register('service-worker.js').then(function(registration) { console.log('service worker 注册成功'); }).catch(function (err) { console.log('servcie worker 注册失败') }); }

1
2
3
4
5
6
7
if (navigator.serviceWorker) {
    navigator.serviceWorker.register('service-worker.js').then(function(registration) {
        console.log('service worker 注册成功');
    }).catch(function (err) {
        console.log('servcie worker 注册失败')
    });
}

在上述代码中,注册了service-worker.js作为当前路径下的service worker。由于service worker的权限很高,所有的代码都需要是安全可靠的,所以只有https站点才可以使用service worker,当然localhost是一个特例。
注册完毕,现在开始写service-worker.js代码。
根据前面的生命周期图,在一个新的service worker被注册以后,首先会触发install事件,在service-workder.js中,可以通过监听install事件进行一些初始化工作,或者什么也不做。
因为我们是要缓存离线文件,所以可以在install事件中开始缓存,但是只是将文件加到caches缓存中,真正想让浏览器使用缓存文件需要在fetch事件中拦截

JavaScript

var cacheFiles = [ 'about.js', 'blog.js' ]; self.addEventListener('install', function (evt) { evt.waitUntil( caches.open('my-test-cahce-v1').then(function (cache) { return cache.addAll(cacheFiles); }) ); });

1
2
3
4
5
6
7
8
9
10
11
var cacheFiles = [
    'about.js',
    'blog.js'
];
self.addEventListener('install', function (evt) {
    evt.waitUntil(
        caches.open('my-test-cahce-v1').then(function (cache) {
            return cache.addAll(cacheFiles);
        })
    );
});

首先定义了需要缓存的文件数组cacheFile,然后在install事件中,缓存这些文件。
evt是一个InstallEvent对象,继承自ExtendableEvent,其中的waitUntil()方法接收一个promise对象,直到这个promise对象成功resolve之后,才会继续运行service-worker.js。
caches是一个CacheStorage对象,使用open()方法打开一个缓存,缓存通过名称进行区分。
获得cache实例之后,调用addAll()方法缓存文件。

这样就将文件添加到caches缓存中了,想让浏览器使用缓存,还需要拦截fetch事件

JavaScript

// 缓存图片 self.addEventListener('fetch', function (evt) { evt.respondWith( caches.match(evt.request).then(function(response) { if (response) { return response; } var request = evt.request.clone(); return fetch(request).then(function (response) { if (!response && response.status !== 200 && !response.headers.get('Content-type').match(/image/)) { return response; } var responseClone = response.clone(); caches.open('my-test-cache-v1').then(function (cache) { cache.put(evt.request, responseClone); }); return response; }); }) ) });

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
// 缓存图片
self.addEventListener('fetch', function (evt) {
    evt.respondWith(
        caches.match(evt.request).then(function(response) {
            if (response) {
                return response;
            }
            var request = evt.request.clone();
            return fetch(request).then(function (response) {
                if (!response && response.status !== 200 && !response.headers.get('Content-type').match(/image/)) {
                    return response;
                }
                var responseClone = response.clone();
                caches.open('my-test-cache-v1').then(function (cache) {
                    cache.put(evt.request, responseClone);
                });
                return response;
            });
        })
    )
});

通过监听fetch事件,service worker可以返回自己的响应。

首先检缓存中是否已经缓存了这个请求,如果有,就直接返回响应,就减少了一次网络请求。否则由service workder发起请求,这时的service workder起到了一个中间代理的作用。

service worker请求的过程通过fetch api完成,得到response对象以后进行过滤,查看是否是图片文件,如果不是,就直接返回请求,不会缓存。

如果是图片,要先复制一份response,原因是request或者response对象属于stream,只能使用一次,之后一份存入缓存,另一份发送给页面。
这就是service worker的强大之处:拦截请求,伪造响应。fetch api在这里也起到了很大的作用。

 

service worker的更新很简单,只要service-worker.js的文件内容有更新,就会使用新的脚本。但是有一点要注意:旧缓存文件的清除、新文件的缓存要在activate事件中进行,因为可能旧的页面还在使用之前的缓存文件,清除之后会失去作用。

 

在初次使用service worker的过程中,也遇到了一些问题,下面是其中两个

数据的聚合

很多时候,视图上需要的数据与数据库存储的形态并不完全相同,在数据库中,我们总是倾向于储存更原子化的数据,并且建立一些关联,这样,从这种数据想要变成视图需要的格式,免不了需要一些聚合过程。

通常我们指的聚合有这么几种:

  • 在服务端先聚合数据,然后再把这些数据与视图模板聚合,形成HTML,整体输出,这个过程也称为服务端渲染
  • 在服务端只聚合数据,然后把这些数据返回到前端,再生成界面
  • 服务端只提供原子化的数据接口,前端根据自己的需要,请求若干个接口获得数据,聚合成视图需要的格式,再生成界面

大部分传统应用在服务端聚合数据,通过数据库的关联,直接查询出聚合数据,或者在Web服务接口的地方,聚合多个底层服务接口。

我们需要考虑自己应用的特点来决定前端数据层的设计方案。有的情况下,后端返回细粒度的接口会比聚合更合适,因为有的场景下,我们需要细粒度的数据更新,前端需要知道数据之间的变更联动关系。

所以,很多场景下,我们可以考虑在后端用GraphQL之类的方式来聚合数据,或者在前端用类似Linq的方式聚合数据。但是,注意到如果这种聚合关系要跟WebSocket推送产生关联,就会比较复杂。

我们拿一个场景来看,假设有一个界面,长得像新浪微博的Feed流。对于一条Feed而言,它可能来自几个实体:

Feed消息本身

JavaScript

class Feed { content: string creator: UserId tags: TagId[] }

1
2
3
4
5
class Feed {
  content: string
  creator: UserId
  tags: TagId[]
}

Feed被打的标签

JavaScript

class Tag { id: TagId content: string }

1
2
3
4
class Tag {
  id: TagId
  content: string
}

人员

JavaScript

class User { id: UserId name: string avatar: string }

1
2
3
4
5
class User {
  id: UserId
  name: string
  avatar: string
}

如果我们的需求跟微博一样,肯定还是会选择第一种聚合方式,也就是服务端渲染。但是,如果我们的业务场景中,存在大量的细粒度更新,就比较有意思了。

比如说,如果我们修改一个标签的名称,就要把关联的Feed上的标签也刷新,如果之前我们把数据聚合成了这样:

JavaScript

class ComposedFeed { content: string creator: User tags: Tag[] }

1
2
3
4
5
class ComposedFeed {
  content: string
  creator: User
  tags: Tag[]
}

就会导致无法反向查找聚合后的结果,从中筛选出需要更新的东西。如果我们能够保存这个变更路径,就比较方便了。所以,在存在大量细粒度更新的情况下,服务端API零散化,前端负责聚合数据就比较合适了。

当然这样会带来一个问题,那就是请求数量增加很多。对此,我们可以变通一下:

做物理聚合,不做逻辑聚合。

这段话怎么理解呢?

我们仍然可以在一个接口中一次获取所需的各种数据,只是这种数据格式可能是:

JavaScript

{ feed: Feed tags: Tags[] user: User }

1
2
3
4
5
{
  feed: Feed
  tags: Tags[]
  user: User
}

不做深度聚合,只是简单地包装一下。

在这个场景中,我们对数据层的诉求是:建立数据之间的关联关系。

小结

通过本节对渐进式Web应用的介绍,相信大家对PWA是什么已经有了基本的认识。PWA有无需担心有无网络的特点,并具有独立入口与独立的保护机制。新标准的推出很可能会带着 Web 应用在移动设备上浴火重生。所以满足 PWA 模型的前端控件,如纯前端表格控件SpreadJS,将逐渐成为移动操作系统的一等公民,并将向Native APP发起挑战。

在下节中我们将带你一起去看看,PWA的原理是什么,以及它究竟是如何工作的,敬请期待。

1 赞 1 收藏 评论

图片 11

问题1. 运行时间

service worker并不是一直在后台运行的。在页面关闭后,浏览器可以继续保持service worker运行,也可以关闭service worker,这取决与浏览器自己的行为。所以不要定义一些全局变量,例如下面的代码(来自):

JavaScript

var hitCounter = 0; this.addEventListener('fetch', function(event) { hitCounter ; event.respondWith( new Response('Hit number ' hitCounter) ); });

1
2
3
4
5
6
7
8
var hitCounter = 0;
 
this.addEventListener('fetch', function(event) {
  hitCounter ;
  event.respondWith(
    new Response('Hit number ' hitCounter)
  );
});

返回的结果可能是没有规律的:1,2,1,2,1,1,2….,原因是hitCounter并没有一直存在,如果浏览器关闭了它,下次启动的时候hitCounter就赋值为0了
这样的事情导致调试代码困难,当你更新一个service worker以后,只有在打开新页面以后才可能使用新的service worker,在调试过程中经常等上一两分钟才会使用新的,比较抓狂。

综合场景

以上,我们述及四种典型的对前端数据层有诉求的场景,如果存在更复杂的情况,兼有这些情况,又当如何?

Teambition的场景正是这么一种情况,它的产品特点如下:

  • 大部分交互都以对话框的形式展现,在视图的不同位置,存在大量的共享数据,以任务信息为例,一条任务数据对应渲染的视图可能会有20个这样的数量级。
  • 全业务都存在WebSocket推送,把相关用户(比如处于同一项目中)的一切变更都发送到前端,并实时展示
  • 很强调无刷新,提供一种类似桌面软件的交互体验

比如说:

当一条任务变更的时候,无论你处于视图的什么状态,需要把这20种可能的地方去做同步。

当任务的标签变更的时候,需要把标签信息也查找出来,进行实时变更。

甚至:

  • 如果某个用户更改了自己的头像,而他的头像被到处使用了?
  • 如果当前用户被移除了与所操作对象的关联关系,导致权限变更,按钮禁用状态改变了?
  • 如果别人修改了当前用户的身份,在管理员和普通成员之间作了变化,视图怎么自动变化?

当然这些问题都是可以从产品角度权衡的,但是本文主要考虑的还是如果产品角度不放弃对某些极致体验的追求,从技术角度如何更容易地去做。

我们来分析一下整个业务场景:

  • 存在全业务的细粒度变更推送 => 需要在前端聚合数据
  • 前端聚合 => 数据的组合链路长
  • 视图大量共享数据 => 数据变更的分发路径多

这就是我们得到的一个大致认识。

问题2. 权限太大

当service worker监听fetch事件以后,对应的请求都会经过service worker。通过chrome的network工具,可以看到此类请求会标注:from service worker。如果service worker中出现了问题,会导致所有请求失败,包括普通的html文件。所以service worker的代码质量、容错性一定要很好才能保证web app正常运行。

 

参考文章:

1. 

2. 

3. 

4. 

5. 

1 赞 3 收藏 评论

图片 12

技术诉求

以上,我们介绍了业务场景,分析了技术特点。假设我们要为这么一种复杂场景设计数据层,它要提供怎样的接口,才能让视图使用起来简便呢?

从视图角度出发,我们有这样的诉求:

  • 类似订阅的使用方式(只被上层依赖,无反向链路)。这个来源于多视图对同一业务数据的共享,如果不是类似订阅的方式,职责就反转了,对维护不利
  • 查询和推送的统一。这个来源于WebSocket的使用。
  • 同步与异步的统一。这个来源于缓存的使用。
  • 灵活的可组合性。这个来源于细粒度数据的前端聚合。

根据这些,我们可用的技术选型是什么呢?

本文由无需申请自动送彩金68发布于无需申请自动,转载请注明出处:复杂单页应用的数据层设计,入门教程

关键词: