疯了吧!这帮人居然用 Go 写“前端”?(二)

疯了吧!这帮人居然用 Go 写“前端”?(二)_第1张图片

作者 | 郑嘉涛(羣青)
来源|尔达 Erda 公众号

前言

上篇我们讲了故事发生的背景,也简单阐述了组件及协议的设想:

一、丰富的通用组件库。
二、组件渲染能力,将业务组件渲染成通用组件。
三、协议渲染能力,以处理复杂交互。

以及这种开发模式带来的好处:

这样的设计初衷旨在大量减少前端工作,尤其是前后端对接方面,甚至可以认为对接是“反转”的,体现在两个层面:接口定义的反转和开发时序的变化。

如果你对我们的设计思路还不够了解,可以先阅读上篇:《疯了吧!这帮人居然用 Go 写“前端”?(一)》。

本篇我将更细致地介绍组件渲染和协议渲染,以及如何通过这两种渲染做到前端彻底不关注业务。

当然最后你会发现是否 REST 并非重要,重要的是合理的切分关注点,而框架只是运用切分的帮助手段。

组件渲染

具体而言,针对一个通用组件,如何完成业务逻辑?

比如说下面同样的一个卡片组件(Card),它由通用的元素构成和呈现:
疯了吧!这帮人居然用 Go 写“前端”?(二)_第2张图片

cardComp:
  props:
    titleIcon: bug-icon
    title: Title
    subContent: Sub Content
    description: Description

但是,通过不同的 props,可以渲染出不同的场景。

场景 1:需求卡片

疯了吧!这帮人居然用 Go 写“前端”?(二)_第3张图片

kanbanCardComp:
  props:
    titleIcon: requirement-icon
    title: 一个简单的需求
    subContent: 完成容器扩容不抖动
    description: 需要存储记录用户的扩容改动,通过调用内部封装的 k8s 接口以实现。

场景 2:打包任务卡片

疯了吧!这帮人居然用 Go 写“前端”?(二)_第4张图片

taskCardComp:
  props:
    titleIcon: flow-task-icon
    title: buildpack (java)
    subContent: ✅ success
    description: time 02:09, begin at 10:21 am ...

对于后端来说,只需要遵循通用组件的数据定义,根据组件渲染器的规则,实现渲染方法即可(需要强调的是,后端不需要知道 UI 的长相,后端面对的始终是数据)。

func Render(ctx Context, c *Comp) error {
  // 1. query db or internal service
  // 2. construct comp
  return nil
}

在交互方面,我们也需要通用组件定义所有的操作,操作(operation)可以认为是交互的影响或者说结果。举个例子,其实查询渲染就是最基础的一种操作;而对于需求卡片来说,点击查看详情,右上角的删除、编辑等都是操作:
疯了吧!这帮人居然用 Go 写“前端”?(二)_第5张图片

不过在通用组件层面,无需感知业务,定义的都是通用的 click, menu-list 等操作,由业务组件实现具体的业务。
疯了吧!这帮人居然用 Go 写“前端”?(二)_第6张图片

前端在呈现层表述的交互(比如悬浮、点击、释放等),最终都会对应到通用组件定义的操作,而操作即是一次标准的组件渲染请求。可以这么思考:假设页面已经呈现在用户面前了,用户通过鼠标(也可能是触摸板)触发的浏览器交互事件,都由前端“呈现器”翻译成组件操作(operation),比如说删除操作,一旦执行操作组件便会触发重新渲染。

下面的伪代码表述了操作在渲染中的体现:

// 伪代码,精简了数据结构和条件判断
func Render(ctx Context, c *Comp, ops string) error {
  if ops != "view" {
    doOps()
  }
  // continue render (aka re-render)
  return nil
}

是不是缺了点什么?没错,后端也无法凭空变出一个卡片。组件渲染必须要有输入的部分,可能是用户直接或者间接的输入。比如用户说:“我想要看 id=42 的需求卡片”,这就是直接的输入,一般会在 url 上体现。另一种情况则是间接的输入:“我想要看 status = DONE 的所有需求卡片“,那么针对某一张需求卡片而言,它所需的 id,是从另一个组件 - 需求列表中获得的。

具体这个数据怎么在组件间绑定,我们会在后续章节(协议渲染)中详细阐述。现在只需要知道,对于单个组件的渲染(也就是业务组件)而言,我们规范了开发者只需要定义组件渲染必要的输入。这是一个很有吸引力的做法,通过参数屏蔽外界逻辑,能够有效地做到高内聚和低耦合。

当然有输入就有输出(要知道数据绑定肯定是把一个组件的输出绑定在另一个组件的输入)。当然交互其有状态的特性(在协议渲染中会详细阐述),我们最终让输入输出合并在一个 state 中体现,仍然是需求卡片的例子:

kanbanCardComp:
  props:
    titleIcon: requirement-icon
    title: 一个简单的需求
    subContent: 完成容器扩容不抖动
    description: 需要存储记录用户的扩容改动,通过调用内部封装的 k8s 接口以实现。
  state:
    ticketId: 42

疯了吧!这帮人居然用 Go 写“前端”?(二)_第7张图片

协议渲染

这里我们需要引申一个实际的问题,以 web ui 为例:当用户访问一个页面时,这个页面并非只有一个组件,比如事项看板页面,就有诸如过滤器、看板甬道、事项卡片、类型切换器等多个组件。

并且,有个头疼的问题:组件之间显然是有联动的。比如过滤器的过滤条件控制了看板甬道的列表结果。
传统的 web 开发,这些联动肯定是由前端代码来实现的。但如果前端来实现这些联动关系,显然就需要深度理解和参与业务了,这与我们整个设计思路是违背的。

这里需要我们有个清晰的认知:在实际的场景中,绝不是标准化单个组件的结构后,前后端就能彻底分离的。换言之,仅将结构的定义由后端转移到前端,只达成了一半:在静态层面解耦了前后端。

而另一半,需要我们将组件间联动、对组件的操作、操作导致重新渲染等,也能由渲染器进行合适处理,也就是在动态层面解耦前后端。

在讲组件渲染的时候我们刻意留了一个悬念:为了保持组件的高内聚低耦合,我们将组件需要的所有输入都参数化,并将输入和输出参数合称为“状态”(state)。那如何将参数、状态串联起来,完成整个页面的逻辑呢?

想想其实也很简单,我们需要有一个协议去规范定义这些依赖关系和传递方式,详见如下形式。

protocol.yaml:

// 组件初始值
component:
  kanbanCardComp:
	  state:
      // ticketId: ??
    operations:
      click:
        reload: true
  ticketDetailDrawerComp:
    state:
      visible: false
      // ticketId: ??
    operations:
      close:
        reload: true
// 渲染过程
rendering:
  __Trigger__:
    kanbanCardComp:
      operations:
        click: set ticketDetailDrawerComp.state.visible = true
    ticketDetailDrawerComp:
      operations:
        close: set ticketDetailDrawerComp.state.visible = false
  __Default__:
    kanbanCardComp:
      state:
        ticketId: {{ url.path.2 }}
    ticketDetailDrawerComp:
      state:
        ticketId: {{ kanbanCardComp.state.ticketId }}

在进行协议渲染时,首先执行 __Trigger__ 部分,操作类型的渲染会临时性地修改部分组件的状态;其次执行 __Default__ 部分,进行组件之间的数据绑定;最后会进行单个业务组件的渲染,这部分在第一篇文章中已经详细阐述。

不过最终需要将这个协议渲染之后给到前端,因为 rendering 不过只是过程数据,最终需要转化成平凡的值。以这个例子而言,(假设用户进行了卡片的 click 操作)协议最终渲染成:

component:
  kanbanCardComp:
    props:
      // 后端组件基于 ticketId=42 渲染出的具体数据
      titleIcon: requirement-icon
      title: 一个简单的需求
      subContent: 完成容器扩容不抖动
      description: 需要存储记录用户的扩容改动,通过调用内部封装的 k8s 接口以实现。
	  state:
      ticketId: 42
    operations:
      click:
        reload: true
  ticketDetailDrawerComp:
    props:
      // 后端组件基于 ticketId=42 渲染出的具体数据
      ...
    state:
      visible: true
      ticketId: 42
    operations:
      close:
        reload: true

值得强调的一点是,前端不需要知道组件之间的联动。所有的联动,都通过重新渲染来实现。这意味着,每次操作,会导致重新渲染这个协议。而从内部来说,则是先进行操作的落实(比如删除、更新),即调用确定的接口执行操作,然后进行场景的重新渲染。

简单的说就是前端每次发生操作,只要告诉后端我操作了什么(operation),后端执行操作之后立刻刷新页面,当然实际的流程会稍微复杂。
疯了吧!这帮人居然用 Go 写“前端”?(二)_第8张图片

从上图中我们可以看到,每次的操作是非常“短视”的,尤其是前端可以说只需要“告诉”后端做了什么操作,别的一概无需知晓。那么就会有人问了:如果某次操作需要传递数据怎么办?比如传统的对接方式,如果要删除一个资源,前端就必须传入后端资源的 ID。那就需要讲到协议必须要有的一个特性:状态。

RESTful API 是无状态的,但是业务逻辑需要有先后顺序,势必就需要存在状态。传统的做法是由前端维系这个状态,尤其是 SPA 更是将所有的状态都维系在内存。

举个例子,比如一个编辑表单,首先打开表单之后,前端需要调用后端接口传入资源 ID 取得数据,并将数据 copy 进表单进行渲染;当保存按钮 click 触发时,需要取得表单中当前值,并调用后端 save 接口进行保存。

我们知道,当前端不关心业务时,状态的维系也随之破碎。这个状态必须要下沉到和渲染同一个位置,准确的说是协议渲染这一层(因为组件单体我们刻意设计成内聚和无状态)。
疯了吧!这帮人居然用 Go 写“前端”?(二)_第9张图片

如何做到状态的下移呢?其实也非常简单,我们知道一个事实,那就是操作之前必定渲染(也就是只有访问了页面才能在页面上点击)。我们只需要在渲染的时候提前预判之后操作所需要的全部数据,提前内置在协议中;而前端在执行操作时,将协议以及操作的对象等信息悉数上报即可。当组件渲染器接收到这个协议的时候,是可以拿到所有需要的参数的(因为本来就是我自己为自己准备的),此时执行完操作后,就开启下一个预判,并重新渲染协议给予前端进行界面呈现。

下面的例子中,可以看到当用户进入第一页(currentPageNo = 1)时,我们早已料到用户会进行下一页(next)操作,就已经把这个操作所需要的参数(pageNo = 2)置于协议之中了;随后用户针对组件 paginationBar 进行了一次操作 next,操作处理时便能拿到所需数据。

components:
  paginationBar:
    state:
      currentPageNo: 1
    operations:
      next:
        reload: true
        meta:
          pageNo: 2

所谓的“早已想到”并非难事,因为各个业务组件中会定义此业务组件实现了通用组件的那些操作,我们要求在定义这些操作的时候,必须要定义这些操作所必须要的外界传入参数(之所以说外界,是因为有些业务参数在组件内部就可以自行处理,而无需依赖外部组件,比如 state 或者 props 的数据信息已经充足)。

最后针对呈现而言,还需要补充组件之间的层级关系,最终形成一个树形的关系,为了布局也需要填充一些“无意义”的组件像 Container、LRContainer 等:
疯了吧!这帮人居然用 Go 写“前端”?(二)_第10张图片

不过这些都是静态的数据,可以直接放入协议,也无需渲染:

hierarchy:
  root: ticketManage
  structure:
    ticketManage:
      - head
      - ticketKanban
    head:
      left: ticketFilter
      right: ticketViewGroup

components:
  ticketManage:
    type: Container
  head:
    type: LRContainer
  ...

暂时告一段落

我们通过组件渲染、协议渲染以及一个通用组件库完成了彻底的前后端分离。不过我们在实践中发现,很多时候彻底的前后端分离会带来一定的困难,这也是我们将认为协议承载的是场景而非页面。

如果是彻底的前后端分离,那势必整个页面甚至整个网站就应该是一个协议,因为只要跳出协议或者说页面间切换,就会有业务含义。但真实情况是,如果一个协议中有太多的组件需要编排,这个复杂编排对于开发者而言是非常繁琐的,并且这个复杂性带来的损失完全淹没彻底前后端分离带来的优势。

从务实角度出发,我们更应该实践“关注点分离”而非是彻底的“前后端分离”。在设计组件以及协议时,我们总是问自己:

  • 前端关注什么?
  • 后端关注什么?
  • 框架/协议应该关注什么?

疯了吧!这帮人居然用 Go 写“前端”?(二)_第11张图片

最终我们框架选择和传统对接方式共存的形式,并且能够友好地互相操作。

比如前端在呈现一个组件的时候,可以选择“偷偷”调用一些 RESTful API 来完成特定的事情,也可以在一个页面中“拼凑“多个协议进行联动等等。

我们也发现,当大量业务逻辑能够从前端下沉到后端时,前端呈现层的逻辑将变得非常简单(数量有限的组件)。我们意外获得了多端支持能力,比如可以实现 CLI 的呈现层,也可以实现 IDE 插件的呈现层等等。

当然我们现在并没有实现这些,不过相信如果是聪明的你,实现这个不难吧~

目前 Erda 的所有代码均已开源,真挚的希望你也能够参与进来!

  • Erda Github 地址:https://github.com/erda-project/erda
  • Erda Cloud 官网:https://www.erda.cloud/

你可能感兴趣的:(云原生,前端,go,paas,go语言)