ISOMORPHIC 的升级之路

ISOMORPHIC 的升级之路

技术杂谈小彩虹2021-08-20 3:29:44400A+A-

首发地址在知乎,由于个人精力有限,可能无法在此进行快速回应。

近些年来,史诗级网游 Web Online 中,一个新兴职业 —— Isomorphic JavaScript Application —— 越来越多地得到了玩家的青睐。

不过作为高阶职业,Isomorphic JavaScript Application,或者称为 Universal JavaScript Application(以下简称 UJS),并不能在创号时直接选择,需要满足前置的种族及职业要求,包括但不仅限于:

  • JavaScript Application(种族);
  • Frontend Application(职业);

而修炼职业 UJS 后,能够将相关技能更进一步地提升,以及习得部分新的高阶技能。

虽然目前已经有不少玩家都宣称自己是 UJS 职业,不过角色与角色的水平差异依然十分巨大。为此,本攻略中将对 UJS 的相关技能以及等级划分进行归纳,方便广大玩家参考。

需要特别注意的是,并非任何战斗中都需要用到所有技能的最高等级,在无意义的情况下空大只是单纯地浪费 MP,请根据自己的实际情况选择合适的技能。

这里拟定战斗场景为一个简单的 Tab 切换,效果类似于(在线示例):

通过点击修改卡片内容

职业技能零:浏览器端渲染

注:该职业由于大部分玩家都已满修,可能不具备研究价值,可根据需要直接跳转到下一技能的攻略内容。

作为 Web 世界的事实专属种族(目前已经一定程度上侵略到其它世界),「浏览器端执行」是 JavaScript 与生俱来的种族技能。

即便如此,鉴于玩家的水平和任务需求,实际使用的技能等级还是具备很大差异:

  • Level 0:无・CSR。应用无法基于静态文件服务器(例如 GitHub Pages)提供。
  • Level 1:伪・CSR。应用获取或生成 HTML 片段,并拼接到页面 HTML 中。
  • Level 2:简・CSR。应用支持全量创建和增量修改页面内容,但需要独立代码实现。
  • Level 3:精・CSR。应用支持全量创建和增量修改页面内容,仅需要一份代码实现。

最早期的 Web 中,所有内容都由服务端页面产生,用户通过超链接访问或者表单提交来进行页面跳转与交互。这时候并不能够进行浏览器端渲染,技能等级为 Level 0。

随着局部刷新需求的出现,部分应用中会通过重置 innerHTML 属性的方式进行内容替换,这样的情况下无需进行整页刷新即可更新内容,使用方式类似于(在线示例):

btn1.addEventListener('click', () => {
  outlet.innerHTML = ` <div class="card" style="width: 20rem;"> <div class="card-body">...</div> </div> `
})

注:为了保持示例代码的简介,整个示例中将不使用任何外部的 JavaScript 依赖,因此只有 VanillaJS 的使用。界面使用 Bootstrap 的默认主题。

这时的技能等级可以达到 Level 1,虽然名义上是局部刷新,但是重新渲染的计算成本较高,并且代码维护及状态管理困难。

为了降低更新视图内容的成本,应用中往往会引入精确视图操作,类似于(在线示例):

btn1.addEventListener('click', () => {
  outlet.querySelector('.card-title').textContent = 'Button 1 Active'
  outlet.querySelector('.card-text span').textContent = 'foo'
})

这样可以有效避免渲染引擎的额外开销,进入到 Level 2。

为了进一步简化维护成本,屏蔽视图操作,可以对视图层进行抽象,而后基于数据驱动的手段来触发视图更新,类似于(在线示例):

<div class="card" style="width: 20rem;">
  <div class="card-body">
    <h5 class="card-title">{{ title }}</h5>
    ...
    <p class="card-text">Card has been changed for {{ count }} time(s).</p>
    ...
  </div>
</div>

注:为了避免在示例中引入外部依赖,示例的源码中直接手写了编译后的模版的类似代码。

这样,视图的创建和更新过程得到了统一,并且由于静态内容与动态数据分离,有效降低了应用维护成本,达到了 Level 3。

职业技能一:服务器端渲染

服务端渲染大体可以分为三个等级:

  • Level 0:无・SSR。服务端返回空白页面,在浏览器端渲染应用视图。
  • Level 1:伪・SSR。服务端返回 App Shell 级别的应用骨架,在浏览器端渲染实际内容。
  • Level 2:准・SSR。服务端返回用户无关的公共内容,在浏览器端补全用户相关内容。
  • Level 3:真・SSR。服务端返回基于用户的完整真实内容。

前端模版可以分为两种类型:渲染前模版渲染后模版。(这里只考虑在浏览器中处理的模版,所有在非浏览器中的预处理操作不在此列)

  • 对于渲染前模版,模版自身不会被浏览器渲染,而是被模版引擎直接作为文本处理。因此模版内容任何情况都不会暴露到页面中。典型代表包括 Angular(JIT)、Vue;
  • 对于渲染后模版,模版自身会被浏览器端当作内容渲染,而后模版引擎基于模版的 DOM 树进行后续操作。如果模版引擎出现错误,模版内容可能被暴露给用户。典型代表包括 AngularJS、Vue。

注:所有手写 Virtual DOM 的场景在机制上等价于渲染前模版。

对于渲染前模版,由于自身并不被浏览器渲染,因此在 JavaScript 执行前无法提供任何内容,以至于初始等级即为 Level 0。不过即便对于渲染后模版,玩家也基本会为了一致性与安全性,通过样式手动屏蔽模版内容(x-cloak),从而主动降级至 Level 0。

示例中假设服务端提供的初始状态为按钮 2 当前活跃,并且已经切换了两次

Level 0 中的首屏渲染效果如下(在线示例):

SSR lv.0 (无 SSR) 效果

注:示例中的导航栏仅用于示例间的跳转,可以视作应用外内容。

这里 SSR 并没有提供任何内容,或者说根本没有 SSR。在没有 CSR(例如 Disable JavaScript)的情况下不具备任何价值。

为了避免完全的白屏,我们可以让 SSR 提供无意义的内容,例如线框图,首屏效果如下(在线示例):

SSR lv.1 (伪 SSR) 效果

注:假装这个是线框图。

这时首屏并不是空白,而是一个向用户表明「渲染中」状态的过渡视图。这样就提升到了 Level 1,伪 SSR。之所以仍然是「伪」,是因为这里的 SSR 自身不交付任何价值,仅仅作为 CSR 的附属(提供渲染加速表象),所以只能算作 CSR+,而非 SSR。

为了让 SSR 能够交付价值,需要在首屏内容中提供实际内容。一个简单的方案是服务端永远作为匿名用户(或者登录中),仅用于产生公共内容,类似于(在线示例):

SSR lv.2 (准 SSR) 效果

这时已经非常接近最终视图,唯一的区别是「Hi, anonymous user」。由于服务端并不处理用户信息,仅仅提供公共可用内容,所以需要在 CSR 阶段将「anonymous user」替换为实际用户名,才算完成视图的实际渲染。

Level 2 已经能够在 SSR 中直接交付价值,即便 CSR 失败或者被禁用,用户仍然可以完成对基本内容的浏览。并且由于内容与用户无关,仍然不需要在服务器端进行计算过程(非实时数据敏感页面),可以在构建时完成全部操作,或者基于事件的预先构建并缓存。

当然,如果有需要,也能在服务器端直接提供最终视图,效果类似于(在线示例):

SSR lv.3 (真 SSR) 效果

为了能够在不使用 CSR 的情况下也能得到最终视图,需要在服务器端进行身份认证(一般基于 Cookie),并且根据用户身份返回专有内容,这时候需要在服务器端进行实时渲染(每个用户的首次访问),可能会占用一定的计算资源。

不过,Level 3 的 SSR 也能提供最为全面的内容交付能力,只要语义化标签使用合理,即便在 Disable JavaScript 的条件下,用户依然能够完成应用的业务流程。

职业技能二:状态过渡

已经单独修炼了 CSR 和 SSR 技能之后,不过要将两者有机结合仍然需要额外的技能。状态过渡大体可以分为三个等级:

  • Level 0:Rebuild。销毁 SSR 产生的全部内容,由 CSR 重新创建内容。
  • Level 1:Rehydrate。在可能的情况下复用 SSR 的视图节点,不再重新创建。
  • Level 2:Resume。集成 SSR 的应用状态,不再重复初始化过程(例如 API 请求)。
  • Level 3:Replay。将 CSR 发生之前的用户交互过程反映到 CSR 结果。

融合 SSR 与 CSR 的最简单方案是:移除所有 SSR 的内容,然后以全新的面貌进行 CSR。这时候如果内容较多,可能会造成页面的卡顿或者闪烁,并且如果存在当前选中文本内容也会被一并清除,效果类似于(在线示例):

Transition lv.0 (Rebuild) 效果

Level 0 虽然操作简单,但容易对用户造成明显的不适感。

为了避免页面节点的重绘,可以在 CSR 过程中复用 SSR 结果中已经存在的元素节点,能够一定程度上优化过渡效果(在线示例):

Transition lv.1 (Rehydrate) 效果

到了 Level 1 阶段,由于视图节点得到了复用,过渡的体验得到了一定的提升(比如文本选中状态得到了保留)。

重用视图节点的过程一般称为 Hydration,其中会对普通的视图节点进行一定的预处理,以便于运行时类库的使用。不过本示例中其实并没有实际的处理过程。

不过,很容易发现,当前的 CSR 过程虽然复用了节点,仍然没有复用 SSR 中的应用状态,而是重新初始化了应用。为了实现状态复用,可以在 SSR 过程中将应用状态进行序列化,而后由 CSR 过程读取:

<script id="application-state" type="application/json"> { "title": "Button 2 Active", "count": 2 } </script>

而后 CSR 中便可复用 SSR 的应用状态,类似于(在线示例):

Transition lv.2 (Resume) 效果

到了 Level 2 之后,不仅节点保持不变,而且应用状态也被保持,基本对用户透明。

不过还有一个问题是,在 CSR 开始之前,如果用户尝试对应用进行交互,那么其操作会被无视,类似于:

Transition lv.2 (Resume) 效果

为了能够允许在 CSR 发生前进行一定程度的交互,需要进行事件重放。简单来说需要预先引入一个极小的运行时(原则上应当放在 <head> 内,必要情况下可以内嵌),基于事件代理来记录相关事件,形如:

export function record(eventNames) {
  for (const eventName of eventNames) {
    document.addEventListener(eventName, (event) => {
      list.push({ name: eventName, element: event.target })
    })
  }
}

注:实践中应当基于应用根节点而非文档根节点,以免记录到应用外部事件。

之后就可以在 CSR 启动完成后重放相关事件:

export function replay() {
  for (const { name: eventName, element } of list) {
    element.dispatchEvent(new Event(eventName))
  }
}

接着就能升级到 Level 3,在 CSR 开始前的交互过程也能够被记录(在线示例):

Transition lv.3 (Replay) 效果

实际应用中,交互与交互之间可能是相互影响的,为此需要定义 Critical Events,例如:

  • Critical Events:button->click,input->focusout;
  • Non-Critical Events:input->input,*->mouseenter;

Non-Critical Events 允许连续发生,而一旦出现 Critical Events 则立刻阻止用户后续交互(例如弹出遮罩层),直到 CSR 启动并且响应 Critical Events 之后,再重新开放交互,从而避免不预期的应用状态。

总结

虽然看攻略会一定程度上减少探索的乐趣,不过迫于生活的压力可能更看重通关效率。不论哪个种族哪种职业,打怪升级之路都绝非一帆风顺。不过在了解攻略后,是否对这个职业的角色更感兴趣了呢?

点击这里复制本文地址 以上内容由权冠洲的博客整理呈现,请务必在转载分享时注明本文地址!如对内容有疑问,请联系我们,谢谢!

支持Ctrl+Enter提交

联系我们| 本站介绍| 留言建议 | 交换友链 | 域名展示 | 支付宝红包
本站资源来自互联网收集,仅供用于学习和交流,请遵循相关法律法规,本站一切资源不代表本站立场,如有侵权、后门、不妥请联系本站删除

权冠洲的博客 © All Rights Reserved.  Copyright quanguanzhou.top All Rights Reserved
苏公网安备 32030302000848号   苏ICP备20033101号-1
本网站由 提供CDN/云存储服务

联系我们