SPA 开发的一点思考
date
Apr 29, 2021
note
slug
spa-ui-development
type
Post
status
Published
tags
技术
Web
summary
回想最近独立负责开发的一个需求：App 中的一个子模块，客户端提供的 WebView 加载网页，实现的一个单页应用（SPA）。其中功能拆分到多个不同的子页面分别实现，各个子页面实质上只作为这一 WebView 页面中的一个模块，通过 React Router 去分发路由和渲染它们。
回想最近独立负责开发的一个需求：App 中的一个子模块，客户端提供的 WebView 加载网页，实现的一个单页应用（SPA）。其中功能拆分到多个不同的子页面分别实现，各个子页面实质上只作为这一 WebView 页面中的一个模块，通过 React Router 去分发路由和渲染它们。
从交互同学手上拿到的流程图，大致描述了各子页面的元素和用户的跳转关系。而流程图背后，并未体现出页面的堆叠关系、哪一块内容需要生成滚动、层级如何安排等更立体的结构等信息。
对于「Web 前端开发」这一角色而言，一开始我很自然而然就以一种「切图仔」的思维，直接开始对着视觉稿开撸；做的时候遇到矛盾、才一点点去反推交互视觉同学去对齐和明确各个细节，甚至有时候他们也并未想清楚这个问题，导致视觉和交互变更带来的额外工作量（论俺上个月的加班来源）。
对齐细节时，发现一些当下无法调和的矛盾，主要与页面栈管理有关。「页面栈」主要是移动 App 开发的概念，描述了页面的堆叠和切换的模式，与浏览器的前进后退历史记录相似。这里问题在于，浏览器（WebView）最初的设计是以网页浏览为中心做的，每一次前进或后退操作，会导致整个页面的刷新，无法像移动端 App 那样有很直接的多页面堆叠的模式。同时也未实现类似 Android / iOS 原生 App 那样平滑的过渡动画效果，切换效果也比较生硬。
其中比较严重的问题是，基于 WebView 的 SPA 子页，在数据埋点与上报的场景有着诸多不便，也容易因为多次曝光导致数据分析出现偏差。
从一个较为抽象的视角去观察，这里核心矛盾在于当下 Web 的形态正在从 “文档” 到 “应用” 的方向去转变；而我们基于文档展示的逻辑去承载整个应用的逻辑，导致体验不是太好。现有的 Web GUI 框架（React / Vue / Angular）等本质上也是在调和这两者的矛盾，但它们仅仅只解决了基于文档模型实现 GUI 渲染这一层面的问题，更深一层次的移动端的交互细节并未覆盖得很好，比如刚想到的页面切换场景的各种细节。在桌面端对跨页面的跳转和交互的诉求不是很高，只要实现了基本的界面渲染和多窗口就满足需求，所以问题并不太明显。
显然， Web 在移动端的交互场景下还是缺失了很多东西。类似微信小程序这样的杂交方案，也正是针对这样的缺失做了许多工作，小程序框架层面提供了页面栈的实现，同时补齐许多客户端才有的 API，当它融合 Web 的低开发门槛、分发效率优势与原生 App 的交互体验优势，也开始大肆占领移动互联网市场。
抛开小程序不谈，在基于纯 WebView 的应用开发，这方面似乎还有不少发挥的空间；无论是 SPA 还是 PWA 也好，在移动端的交互需求下，大致都有着类似按页面拆分功能的场景。或许可以基于 React / Vue / Angular 等 GUI 框架之上，设计一套轻量且完善的页面栈管理方案，这样的 SPA 或 PWA ，在使用感受上也可以很接近原生 App 的体验了。
找到的一些不错的文：