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

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

原文出处: 徐飞   

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

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

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

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

知识背景

随着物联网的发展促进传统行业不断转型,在设备间通信的业务场景越来越多。其中很大一部分在于移动端和设备或服务端与设备的通信,例如已成主流的共享单车。但存在一个这样小问题,当指令下发完毕之后,设备不会同步返回指令执行是否成功,而是异步通知或是服务端去主动查询设备指令是否发送成功,这样一来客户端(前端)也无法同步获取指令执行情况,只能通过服务端异步通知来接收该状态了。这也就引出了这篇博客想要探索的一项技术:如何实现服务端主动通知前端?
其实,这样的业务场景还有很多,但这样的解决方案却不是非常成熟,方案概括过来就两个大类。1.前端定时请求轮询
2.前端和服务端保持长连接,以持续进行数据交互,这个可以包括较为成熟的WebSocket。我们可以看看张小龙在知乎问题
如何在大型 Web 应用中保持数据的同步更新?
的回答,更加清楚的认识这个过程。

这个问题在10年前已经被解决过无数次了,最简单的例子就是网页聊天室。题主的需求稍微复杂些,需要支持的数据格式更多,然而只要定义好了通讯规范,多出来的也只是搬砖的活儿了。
整个过程可以分为5个环节:1 包装数据、2 触发通知、3 通讯传输、4
解析数据、5 渲染数据。这5个环节中有三点很关键:1 通讯通道选择、2
数据格式定义、3 渲染数据。

1
通讯通道选择:这个很多前端高手已经回答了,基本就是两种方式:轮询和长连接,这种情况通常的解决方式是长连接,Web端可以用WebSocket来解决,这也是业界普遍采用的方案,比如环信、用友有信、融云等等。通讯环节是相当耗费服务器资源的一个环节,而且开发成本偏高,建议将这些第三方的平台直接集成到自己的项目中,以降低开发的成本。

2
数据格式定义:数据格式可以定义得五花八门,不过为了前端的解析,建议外层统一数据格式,定义一个类似type的属性来标记数据属性(是IM消息、微博数据还是发货通知),然后定义一个data属性来记录数据的内容(一般对应数据表中的一行数据)。统一数据格式后,前端解析数据的成本会大大降低。

3
渲染数据渲染数据是关系到前端架构的,比如是React、Vue还是Angular(BTW:不要用Angular,个人认为Angular在走向灭亡)。这些框架都用到了数据绑定,这已经成为业界的共识了(只需要对数据进行操作,不需要操作DOM),这点不再论述。在此种需求场景下,数据流会是一个比较大的问题,因为可能每一条新数据都需要寻找对应的组件去传递数据,这个过程会特别恶心。所以选择单一树的数据流应该会很合适,这样只需要对一棵树的节点进行操作即可:定义好type和树节点的对应关系,然后直接定位到对应的节点对数据增删改就可以,例如Redux。

以上三点是最核心的环节,涉及到前后端的数据传输、前端数据渲染,其他的内容就比较简单了,也简单说下。

后端:包装数据、触发通知这个对后端来说就很Easy了,建一个队列池,不断的往池子里丢任务,让池子去触发通知。

前端:解析数据解析数据就是多出来的搬砖的活儿,过滤type、取data。技术难度并不大,主要点还是在于如何能低开发成本、低维护成本地达到目的,上面是一种比较综合的低成本的解决方案。

对于对实时性要求较高的业务场景,轮询显然是无法满足需求的,而长连接的缺点在于长期占了服务端的连接资源,当前端用户数量指数增长到一定数量时,服务端的分布式须另辟蹊径来处理WebSocket的连接匹配问题。它的优点也很明显,对于传输内容不大的情况下,有非常快的交互速度,因为他不是基于HTTP请求的,而是浏览器端扩展的Socket通信。

视图间的数据共享

所谓共享,指的是:

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

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

什么是端到端组件呢?

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

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

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

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

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

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

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

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

Spring boot接入WebSocket

服务端推送

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

考虑一个典型场景,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 => {
  // 处理数据
})

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

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

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

Maven Dependencies

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-websocket</artifactId>
</dependency>

缓存的使用

如果说我们的业务里,有一些数据是通过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)
  }
}

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

Config

@Configuration
@EnableWebSocketMessageBroker
public class WebSocketConfig extends AbstractWebSocketMessageBrokerConfigurer {

    @Override
    public void registerStompEndpoints(StompEndpointRegistry stompEndpointRegistry) {
        // 添加服务端点,可以理解为某一服务的唯一key值
        stompEndpointRegistry.addEndpoint("/chatApp");
        //当浏览器支持sockjs时执行该配置
        stompEndpointRegistry.addEndpoint("/chatApp").setAllowedOrigins("*").withSockJS();
    }

    @Override
    public void configureMessageBroker(MessageBrokerRegistry config) {
        // 配置接受订阅消息地址前缀为topic的消息
        config.enableSimpleBroker("/topic");
        // Broker接收消息地址前缀
        config.setApplicationDestinationPrefixes("/app");
    }
}

数据的聚合

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

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

  • 在服务端先聚合数据,然后再把这些数据与视图模板聚合,形成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
}

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

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

MessageMapping

    @Autowired
    private SimpMessagingTemplate template;

    //接收客户端"/app/chat"的消息,并发送给所有订阅了"/topic/messages"的用户
    @MessageMapping("/chat")
    @SendTo("/topic/messages")
    public OutputMessage receiveAndSend(InputMessage inputMessage) throws Exception {
        System.out.println("get message (" + inputMessage.getText() + ") from client!");
        System.out.println("send messages to all subscribers!");
        String time = new SimpleDateFormat("HH:mm").format(new Date());
        return new OutputMessage(inputMessage.getFrom(), inputMessage.getText(), time);
    }

    //或者直接从服务端发送消息给指定客户端
    @MessageMapping("/chat_user")
    public void sendToSpecifiedUser(@Payload InputMessage inputMessage, SimpMessageHeaderAccessor headerAccessor) throws Exception {
        System.out.println("get message from client (" + inputMessage.getFrom() + ")");
        System.out.println("send messages to the specified subscriber!");
        String time = new SimpleDateFormat("HH:mm").format(new Date());
        this.template.convertAndSend("/topic/" + inputMessage.getFrom(), new OutputMessage(inputMessage.getFrom(), inputMessage.getText(), time));
    }

综合场景

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

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

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

比如说:

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

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

甚至:

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

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

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

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

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

clients

<!DOCTYPE html>
<!DOCTYPE html>
<html>

    <head>
        <title>Chat WebSocket</title>
        <script src="http://cdn.jsdelivr.net/sockjs/0.3.4/sockjs.min.js"></script>
        <script src="js/stomp.js"></script>
        <script type="text/javascript">
            var apiUrlPre = "http://10.200.0.126:9041/discovery";
            var stompClient = null;

            function setConnected(connected) {
                document.getElementById('connect').disabled = connected;
                document.getElementById('disconnect').disabled = !connected;
                document.getElementById('conversationDiv').style.visibility = connected ? 'visible' : 'hidden';
                document.getElementById('response').innerHTML = '';
            }

            function connect() {
                var socket = new SockJS('http://localhost:9041/discovery/chatApp');
        var from = document.getElementById('from').value;
                stompClient = Stomp.over(socket);
                stompClient.connect({}, function(frame) {
                    setConnected(true);
                    console.log('Connected: ' + frame);
          //stompClient.subscribe('/topic/' + from, function(messageOutput) {
                    stompClient.subscribe('/topic/messages', function(messageOutput) {
                        //                      alert(messageOutput.body);
                        showMessageOutput(JSON.parse(messageOutput.body));
                    });
                });
            }

            function disconnect() {
                if(stompClient != null) {
                    stompClient.disconnect();
                }
                setConnected(false);
                console.log("Disconnected");
            }

            function sendMessage() {
                var from = document.getElementById('from').value;
                var text = document.getElementById('text').value;
                //stompClient.send("/app/chat_user", {},
                stompClient.send("/app/chat", {},
                    JSON.stringify({
                        'from': from,
                        'text': text
                    })
                );
            }

            function showMessageOutput(messageOutput) {
                var response = document.getElementById('response');
                var p = document.createElement('p');
                p.style.wordWrap = 'break-word';
                p.appendChild(document.createTextNode(messageOutput.from + ": " +
                    messageOutput.text + " (" + messageOutput.time + ")"));
                response.appendChild(p);
            }
        </script>
    </head>

    <body onload="disconnect()">
        <div>
            <div>
                <input type="text" id="from" placeholder="Choose a nickname" />
            </div>
            <br />
            <div>
                <button id="connect" onclick="connect();">Connect</button>
                <button id="disconnect" disabled="disabled" onclick="disconnect();">
                    Disconnect
                </button>
            </div>
            <br />
            <div id="conversationDiv">
                <input type="text" id="text" placeholder="Write a message..." />
                <button id="sendMessage" onclick="sendMessage();">Send</button>
                <p id="response"></p>
            </div>
        </div>

    </body>

</html>

技术诉求

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

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

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

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

结果

威尼斯人线上娱乐 1

send to all subscribers

威尼斯人线上娱乐 2

send to the specified subscriber

主流框架对数据层的考虑

一直以来,前端框架的侧重点都是视图部分,因为这块是普适性很强的,但在数据层方面,一般都没有很深入的探索。

  • React, Vue
    两者主要侧重数据和视图的同步,生态体系中有一些库会在数据逻辑部分做一些事情
  • Angular,看似有Service这类可以封装数据逻辑的东西,实际上远远不够,有形无实,在Service内部必须自行做一些事情
  • Backbone,做了一些业务模型实体和关联关系的抽象,更早的ExtJS也做了一些事情

综合以上,我们可以发现,几乎所有现存方案都是不完整的,要么只做实体和关系的抽象,要么只做数据变化的封装,而我们需要的是实体的关系定义和数据变更链路的封装,所以需要自行作一些定制。

那么,我们有怎样的技术选型呢?

总结

这是spring-boot接入WebSocket最简单的方法了,很直观的表现了socket在浏览器段通信的便利,但根据不同的业务场景,对该技术的使用还需要斟酌,例如如何使WebSocket在分布式服务端保持服务,如何在连接上集群后下发消息找到长连接的服务端机器。我也在为这个问题苦苦思考,思路虽有,实践起来却举步维艰,特别是网上谈到比较多的将连接序列化到缓存中,统一管理读取分配,分享几个好思路,也希望自己能给找到较好的方案再分享一篇博客。
来自Push notifications with websockets in a distributed Node.js
app

  1. Configure Nginx to send websocket requests from each browser to all
    the server in the cluster. I could not figure out how to do it. Load
    balancing does not support broadcasting.
  2. Store websocket connections in the databse, so that all servers had
    access to it. I am not sure how to serialize the websocket
    connection object to store it in MongoDB.
  3. Set up a communication mechanism among the servers in the cluster
    (some kind message bus) and whenever event happens, have all the
    servers notify the websocket clients they are tracking. This
    somewhat complicates the system and requires the nodes to know the
    addresses of each other. Which package is most suitable for such a
    solution?
    再分享几个讨论:
    springsession如何对spring的WebSocketSession进行分布式配置?
    websocket多台服务器之间怎么共享websocketSession?

RxJS

遍观流行的辅助库,我们会发现,基于数据流的一些方案会对我们有较大帮助,比如RxJS,xstream等,它们的特点刚好满足了我们的需求。

以下是这类库的特点,刚好是迎合我们之前的诉求。

  • Observable,基于订阅模式
  • 类似Promise对同步和异步的统一
  • 查询和推送可统一为数据管道
  • 容易组合的数据管道
  • 形拉实推,兼顾编写的便利性和执行的高效性
  • 懒执行,不被订阅的数据流不执行

这些基于数据流理念的库,提供了较高层次的抽象,比如下面这段代码:

JavaScript

function getDataO(): Observable<T> { if (cache) { return
Observable.of(cache) } else { return Observable.fromPromise(fetch(url))
} } getDataO().subscribe(data => { // 处理数据 })

1
2
3
4
5
6
7
8
9
10
11
12
function getDataO(): Observable<T> {
  if (cache) {
    return Observable.of(cache)
  }
  else {
    return Observable.fromPromise(fetch(url))
  }
}
 
getDataO().subscribe(data => {
  // 处理数据
})

这段代码实际上抽象程度很高,它至少包含了这么一些含义:

  • 统一了同步与异步,兼容有无缓存的情况
  • 统一了首次查询与后续推送的响应,可以把getDataO方法内部这个Observable也缓存起来,然后把推送信息合并进去

我们再看另外一段代码:

JavaScript

const permission$: Observable<boolean> = Observable
.combineLatest(task$, user$) .map(data => { let [task, user] = data
return user.isAdmin || task.creatorId === user.id })

1
2
3
4
5
6
const permission$: Observable<boolean> = Observable
  .combineLatest(task$, user$)
  .map(data => {
    let [task, user] = data
    return user.isAdmin || task.creatorId === user.id
  })

这段代码的意思是,根据当前的任务和用户,计算是否拥有这条任务的操作权限,这段代码其实也包含了很多含义:

首先,它把两个数据流task$和user$合并,并且计算得出了另外一个表示当前权限状态的数据流permission$。像RxJS这类数据流库,提供了非常多的操作符,可用于非常简便地按照需求把不同的数据流合并起来。

我们这里展示的是把两个对等的数据流合并,实际上,还可以进一步细化,比如说,这里的user$,我们如果再追踪它的来源,可以这么看待:

某用户的数据流user$ := 对该用户的查询 +
后续对该用户的变更(包括从本机发起的,还有其他地方更改的推送)

如果说,这其中每个因子都是一个数据流,它们的叠加关系就不是对等的,而是这么一种东西:

  • 每当有主动查询,就会重置整个user$流,恢复一次初始状态
  • user$等于初始状态叠加后续变更,注意这是一个reduce操作,也就是把后续的变更往初始状态上合并,然后得到下一个状态

这样,这个user$数据流才是“始终反映某用户当前状态”的数据流,我们也就因此可以用它与其它流组合,参与后续运算。

这么一段代码,其实就足以覆盖如下需求:

  • 任务本身变化了(执行者、参与者改变,导致当前用户权限不同)
  • 当前用户自身的权限改变了

这两者导致后续操作权限的变化,都能实时根据需要计算出来。

其次,这是一个形拉实推的关系。这是什么意思呢,通俗地说,如果存在如下关系:

JavaScript

c = a + b //
不管a还是b发生更新,c都不动,等到c被使用的时候,才去重新根据a和b的当前值计算

1
c = a + b     // 不管a还是b发生更新,c都不动,等到c被使用的时候,才去重新根据a和b的当前值计算

如果我们站在对c消费的角度,写出这么一个表达式,这就是一个拉取关系,每次获取c的时候,我们重新根据a和b当前的值来计算结果。

而如果站在a和b的角度,我们会写出这两个表达式:

JavaScript

c = a1 + b // a1是当a变更之后的新值 c = a + b1 // b1是当b变更之后的新值

1
2
c = a1 + b     // a1是当a变更之后的新值
c = a + b1    // b1是当b变更之后的新值

这是一个推送关系,每当有a或者b的变更时,主动重算并设置c的新值。

如果我们是c的消费者,显然拉取的表达式写起来更简洁,尤其是当表达式更复杂时,比如:

JavaScript

e = (a + b ) * c – d

1
e = (a + b ) * c – d

如果用推的方式写,要写4个表达式。

所以,我们写订阅表达式的时候,显然是从使用者的角度去编写,采用拉取的方式更直观,但通常这种方式的执行效率都较低,每次拉取,无论结果是否变更,都要重算整个表达式,而推送的方式是比较高效精确的。

但是刚才RxJS的这种表达式,让我们写出了形似拉取,实际以推送执行的表达式,达到了编写直观、执行高效的结果。

看刚才这个表达式,大致可以看出:

permission$ := task$ + user$

这么一个关系,而其中每个东西的变更,都是通过订阅机制精确发送的。

有些视图库中,也会在这方面作一些优化,比如说,一个计算属性(computed
property),是用拉的思路写代码,但可能会被框架分析依赖关系,在内部反转为推的模式,从而优化执行效率。

此外,这种数据流还有其它魔力,那就是懒执行。

什么是懒执行呢?考虑如下代码:

JavaScript

const a$: Subject<number> = new Subject<number>() const b$:
Subject<number> = new Subject<number>() const c$:
Observable<number> = Observable.combineLatest(a$, b$) .map(arr
=> { let [a, b] = arr return a + b }) const d$:
Observable<number> = c$.map(num => { console.log(‘here’) return
num + 1 }) c$.subscribe(data => console.log(`c: ${data}`))
a$.next(2) b$.next(3) setTimeout(() => { a$.next(4) }, 1000)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
const a$: Subject<number> = new Subject<number>()
const b$: Subject<number> = new Subject<number>()
 
const c$: Observable<number> = Observable.combineLatest(a$, b$)
  .map(arr => {
    let [a, b] = arr
    return a + b
  })
 
const d$: Observable<number> = c$.map(num => {
  console.log(‘here’)
  return num + 1
})
 
c$.subscribe(data => console.log(`c: ${data}`))
 
a$.next(2)
b$.next(3)
 
setTimeout(() => {
  a$.next(4)
}, 1000)

注意这里的d$,如果a$或者b$中产生变更,它里面那个here会被打印出来吗?大家可以运行一下这段代码,并没有。为什么呢?

因为在RxJS中,只有被订阅的数据流才会执行。

主题所限,本文不深究内部细节,只想探讨一下这个特点对我们业务场景的意义。

想象一下最初我们想要解决的问题,是同一份数据被若干个视图使用,而视图侧的变化是我们不可预期的,可能在某个时刻,只有这些订阅者的一个子集存在,其它推送分支如果也执行,就是一种浪费,RxJS的这个特性刚好能让我们只精确执行向确实存在的视图的数据流推送。

参考

WebSocket
Support

RxJS与其它方案的对比

1. 与watch机制的对比

不少视图层方案,比如Angular和Vue中,存在watch这么一种机制。在很多场景下,watch是一种很便捷的操作,比如说,想要在某个对象属性变更的时候,执行某些操作,就可以使用它,大致代码如下:

JavaScript

watch(‘a.b’, newVal => { // 处理新数据 })

1
2
3
watch(‘a.b’, newVal => {
  // 处理新数据
})

这类监控机制,其内部实现无非几种,比如自定义了setter,拦截数据的赋值,或者通过对比新旧数据的脏检查方式,或者通过类似Proxy的机制代理了数据的变化过程。

从这些机制,我们可以得到一些推论,比如说,它在对大数组或者复杂对象作监控的时候,监控效率都会降低。

有时候,我们也会有监控多个数据,以合成另外一个的需求,比如:

一条用于展示的任务数据 := 这条任务的原始数据 + 任务上的标签信息 +
任务的执行者信息

如果不以数据流的方式编写,这地方就需要为每个变量单独编写表达式或者批量监控多个变量,前者面临的问题是代码冗余,跟前面我们提到的推数据的方式类似;后者面临的问题就比较有意思了。

监控的方式会比计算属性强一些,原因在于计算属性处理不了异步的数据变更,而监控可以。但如果监控条件进一步复杂化,比如说,要监控的数据之间存在竞争关系等等,都不是容易表达出来的。

另外一个问题是,watch不适合做长链路的变更,比如:

JavaScript

c := a + b d := c + 1 e := a * c f := d * e

1
2
3
4
c := a + b
d := c + 1
e := a * c
f := d * e

这种类型,如果要用监控表达式写,会非常啰嗦。

网站地图xml地图