前言
能在PC端花这么多功夫的产品并不多。 今日早读文章由京东@印露实验室授权分享。
正文从这里开始~~
距离上次首页改版已经2年3个月5天了。 与上次改版首页整体框架和开发流程的大刀阔斧相比，这次改版有点像跳水——没有水花。 在站在巨人肩膀上的小巨人的叮嘱和期待下，本次改版在延续17版框架和流程的基础上，在稳定性、安全性、视觉体验、无障碍等方面做到了完美主页体验。 添加了砖块和瓷砖。
本文将从以下几个方面介绍强类型检查的介绍
在性能几乎无懈可击的情况下，我们决定从稳定性入手，在项目中引入强类型检查，弥补Javascript这种弱类型语言的不可预测性。
强类型语言 Typescript 发布已经 6 年多了，国内应用开发者的数量也在慢慢增加。 一般来说，业务开发周期短，迭代频繁。 Typescript 的引入对于大量开发者来说是一项费时费力的工作。 用了就可以上线，不用了也可以上线，所以团队很少在业务上干活。 应用于生产。 但秉承着不折腾不颠簸的理念，新版首页不负众望，进行了基于TS的重构。
做TS重构并不难，把js后缀改成ts就行了。 超过。
当然是开玩笑了！ 显然，这样的TS是没有意义的。 只有严格遵循 TS 标准的代码才能最大限度地发挥 TS 的效用。 在项目中，我们开启严格模式进行TS检查。 每次我们提交时，我们都会对代码进行完整的检查。 只要有TS错误，就禁止提交。 目的是向会员传达一个信息——写强类型语言要有意识，否则就是耍流氓。
没有深入使用过TS的同学，前期可能会觉得日子不好过，但是这些都是为了自己好，保证代码的健壮性。 比如window全局变量的管理，以往很难定位和查找，这让开发者很头疼。 引入TS后，只要对全局变量进行界面设置京东电脑版网页，各个组件中就不会再出现冗余或未知的全局变量。 变量的情况。 再比如写一个有get和set方法的存储类时，TS可以帮助检测获取到的内容类型：
portant;border-width: 1px !important;border-style: solid !important;border-color: rgb(226, 226, 226) !important;">
interface MemoryState {
testa: boolean
testb: string
}
class Controller {
state: StateType
constructor() {
this.state = {
state: {},
}
}
get<K extends MemoryStateKeys>(key: K) {
return this.state.memory[key]
}
set<K extends MemoryStateKeys>(key: K, value: MemoryState[K]): MemoryState[K] {
this.state.memory[key] = value
return value
}
}
当我们使用new Controller().get("testb")时，TS可以在开发阶段检测testb是否为string类型。 通过TS的检测插件，我们可以放心的使用string类型对象的方法，简化复杂的判断逻辑，保证在获取到非预期值时能够及时通过报错找到代码，以及所有输入和输出是稳定的和可预测的。 四舍五入是在写代码的时候自动抽取一部分测试，为项目的开发和迭代保驾护航。
升级资源建设方案
旧主页项目使用的构建工具Athena促进了开发过程的自动化，但是涉及到定制化的构建过程，由于Athena的通用性京东电脑版网页，不方便直接进行修改。 主页包含三种类型的资源引用：直出、同步和异步。 资源打包需要特殊处理。 因此，我们这次回归Webpack，在Webpack 4.0的基础上优化了以下解决方案：
发布流程优化
在老版本的发布过程中，每次发布都需要对改动的文件进行diff检查，避免不符合预期的错误改动。 Webpack默认打包机制的特点是根据模块的打包顺序为每个模块提供一个有顺序编号的ID，并对文件包的依赖进行管理。 旧版首页的入口文件包含依赖包管理的执行环境，所以当任何包的导入顺序发生变化时，入口文件也会发生变化。 在上述打包机制中，当一个文件的导入顺序发生变化时，编译后可能会影响到几个甚至十几个文件的变化，而这些文件中的逻辑代码部分实际上并不需要更新，从而减少了这个影响了diff代码的准确性，使得这个中间校验措施失去了原本的意义。 首页缓存机制和资源惰性机制使得在发布静态资源时需要清除更改文件的CDN缓存，这意味着更改的文件越多，需要清除缓存资源的链接就越多，链接越多，不同步缓存清除导致资源异步加载错误的概率较高，每次上线发布都有一定的风险。
为了降低发布风险，新版首页的打包机制改变了Webpack的打包逻辑。 通过设置，各个模块不再通过顺序编号的ID来管理依赖包，而是通过文件目录生成经过hash编码的专有ID，并把依赖包的执行环境从入口文件中提取出来，作为一个单独的资源请求，这样每一个更改文件时，只能比较更改的文件，从而消除其他意外的差异情况。 通过新的构建方案，将代码变更控制在预期范围内，保证部署过程的稳定性。
项目架构优化
老版本页面的性能优化方案包括一些直接输出的js片段。 这些代码是项目依赖的基础函数，需要在核心js代码执行前启动。 但是这样的方案也有一些不尽如人意的地方：
针对以上问题，我们在新版本中将这些代码放回了核心代码中。 模板代码不再携带任何逻辑代码。 迭代发布不涉及模板发布。 只需要释放静态资源，在开发过程中统一使用。 JS高级语法，免去手动维护兼容语法代码的过程。
至此，我们通过增强资源打包的可预见性，优化项目资源结构，优化了资源释放方案。
访问自动化测试
页面开发完成后，在进行测试之前，自测页面是必不可少的一个环节。 一方面保证页面开发的功能能够正常运行； 另一方面保证了功能开发时，不影响页面其他区域功能的正常使用。
一般来说，自检需要人工进行测试，但是这样会有两个缺点。 一是待测区域数量过多，同类测试操作过于频繁，浪费人力，影响测试效率； 其次，由于人为自测没有统一的自测规范，在测试过程中很容易出现遗漏，从而忽略了一些看似很小但实际影响很大的bug。 测量所需的效果。 针对这种情况，我们萌生了实施自动化测试的想法。 以新版首页为例，我们使用Nightwatch.js创建新版首页的自动化测试脚本，对新版首页的73个用例进行自动化测试。
结果显示，通过自动化测试，不到三分钟就完成了新首页73个用例的测试，这也意味着如果要通过自动化测试对任何页面进行自测，自测时间可控制在五分钟以内，准确度更高。 发布前和发布后5分钟内进行自动化测试，及时检查测试用例，确保每次发布的安全性。
完善监控系统
旧版页面前端监控系统涵盖浏览器信息、页面测速、楼层隐藏等。 但是信息通知比较滞后，只覆盖页面onLoad时间。 当收到告警信息时，无法快速定位问题。
参考京东购物小程序目前的监控机制，新版首页增加了对代码错误上报和接口可用性的上报监控。
代码错误监控：BadJS
通过BadJS框架捕获页面错误，对错误信息进行分析处理并上报给京东BadJS服务。 通过上报数据，我们可以得到错误的详细信息和发生次数。 通过分析上报的数据，可以及时发现并修复一些潜在的问题，保证首页代码的健壮性。 同时，根据报告的数量，也可以预估一个问题造成的影响范围，便于预估损失。
业务可用性监控
本次改版，在可用率上报系统首页增加了具体判断规则，包括通话次数、可用率、TP（绩效指标）三个维度。 在此基础上，这三个维度也可以相互比较，以减少误报的可能性，系统最近推出了闯红灯警告——语音通知功能。
可用性上报系统一般用于监控界面可用性，但是对于首页来说，除了界面之外，还需要关注隐藏楼层的情况。 在目前的自下而上的解决方案中，当每层楼的所有模块接口都失效时，当前楼层将被隐藏。 一旦地板被隐藏起来，就说明问题严重了，需要引起重视并迅速解决。 可用性上报系统可在触发报警规则后1分钟内推送通知，精准到接口，便于及时发现问题，及时止损。 需要注意的是，如何设置一套能够更准确地反映问题的发生，减少误报的阈值显得尤为重要。 毕竟狼叫多了就代表没有监控。
速度报告
这部分继续沿用旧版Athena的测速上报方案，减去部分与业务数据上报重复的部分。 同时增加接口测速上报，完善故障溯源数据体系。
优化页面加载体验：
老版本页面懒加载的placeholder解决方案，采用统一的区域加载动画方式。 这种方式的优点是复用成本低，适应性强。 但是如果遇到大面积的模块或者比较密集的模块，区域加载动画的体验会下降——要么空白区域过大，要么加载动画过于密集，模块造成的视觉效果loading process 的感知差异更加明显。 对于PC主页来说，主要的问题是留白空间太大。
在本次改版中，我们引入了骨架屏方案，最终目的是尽量减少真实模块结构与以灰豆腐块形式加载的视觉差异。 实现上根据视觉上的不同可以分为两种对应：
考虑到首页的特殊性，我们最终选择了对应性强的骨架屏方案，并且出于可扩展性的考虑，我们使用了带样式渲染的骨架屏，而不是直接使用图片占位符。 除了开发成本的增加，页面首屏加载的代码量也增加了。
项目结构
使用骨架屏要实现的效果包括以下几点：
意思是骨架屏的内容需要和页面同步加载。 结合懒加载组件，需要将骨架屏组件作为加载结构体提前传入，并在页面渲染时第一时间加载样式，否则骨架会失去屏幕意义。
每个需要骨架屏样式的组件都被拆分成一个占位符组件。 组件中的placeholder结构包含两种样式——颜色和尺寸定位，加上容器外层的动画效果样式。 颜色样式是整个页面通用的，尺寸定位样式是形式组件通用的：
与官方组件共享大小定位样式的目的是为了保证以后组件样式变化时骨架屏和官方样式的统一修改，避免样式修改出现遗漏，但同时增加样式的维护成本。 同时，开发者在样式编写和拆分的过程中，也需要注意兼容骨架屏的样式。 比如需要占用豆腐块的容器之间padding和margin的选择就很重要。 因此，首页的骨架屏尝试不适合快速复用到其他项目。
全新首页骨架屏加载体验
优化信息无障碍体验
互联网信息无障碍，即为视障人士提供的帮助。 系统级辅助主要依靠读屏工具，可以解决网页60%的信息无障碍障碍，剩下的40%需要开发者在网页开发过程中进行优化。
没有进行任何信息无障碍处理的网页在使用屏幕阅读器访问时一般会出现以下问题：
为了造福全国110人中的一位视障人士（数据来自这里），本次改版，我们决定在PC首页首推京东桌面端信息无障碍实践。
视障用户在桌面上的操作主要是通过键盘进行的。 针对刚才提出的问题，初期的PC首页无障碍体验优化方案分为几个阶段。
第一阶段，对所有tab可访问的元素进行语义化——将包含页面外跳转链接的标签统一添加aria-label属性，使屏幕阅读器可以简化阅读元素信息；
第二阶段，保证页面主要模块的访问——懒加载内容占用容器，将tab-index设置为大于0的值，这样就可以遍历tab键，从而触发延迟加载页面，避免直接跳过选项卡；
第三阶段，扩展弹出浮层等元素的操作——为无障碍添加弹出浮层交互逻辑，为入口添加aria-haspopup属性，告诉读屏软件这是该入口的入口弹出浮层，并设置tab-index为大于0的值，使tab操作获得焦点，浮层弹出后焦点自动聚焦到浮层上；
第四阶段是为视障用户添加额外的快速跳转——参考谷歌搜索结果页面，在页面顶部添加一些隐藏的快速跳转。 此次PC版首页在搜索框和底部的“为你推荐”位置增加了隐藏跳转链接，只有使用键盘操作的用户才能定位。
对于商城页面来说，第一阶段可以满足基本的内容访问，如果能够做到第四阶段，就可以算是一个完整的信息无障碍网站了。 在商城业务中，无障碍体验一直缺乏相应的规范和流程。 因此，通过本次PC首页改版实践，输出了商城渠道页无障碍信息化开发规范，包括：
未来，该规范将用于优化商城其他业务的无障碍体验。
综上所述，本次改版对开发者最大的改变是本地开发体验更舒适，发布风险降低，故障追踪更完善。 对于用户来说，页面加载的跳动感大大降低，视障用户的体验终于得到照顾。 作为商城桌面端的入口和门面，首页的提升绝不能就此止步。 希望每一次改版都能有一点点的优化，让首页的项目更接近完美。
本文作者简介：@何Jason，EC，小屁 原文：
推荐给你
