重构招聘中心求职体验

我们如何快速构建并发布了招聘中心全新的移动端友好求职体验。

对前端开发者而言，一个有点可怕的噩梦是听到“是的”来回应那个令人畏惧的问题：“我们要为移动网页发布这个吗？”。你首先会想这将对估算产生什么影响……然后是测试……字体大小……性能……当你突然注意到视线开始模糊时，你的头开始发晕……

不久前，在upGrad负责招聘中心的几位开发者遇到了类似的情况。我们的任务是将流畅、焕然一新的求职体验带到移动网页上。

移动网页（mWeb）——为何它并未过时

在整个互联网上，提示安装原生应用的转化率通常低于4%。允许一个原生应用占据你最私人的设备（手机）的屏幕空间，仍然被视为一种长期承诺——你需要先吸引用户，然后激励他们安装它。因此，除非你的应用能实现移动浏览器在技术上无法实现的功能、解决高频使用场景或需要更高的安全性——否则你的关键重点仍应放在移动优先的网页应用上！

mWeb还允许我们比原生应用更快地将关键功能带给用户！它是一个更容易进行A/B测试的平台，我们经常使用mWeb来收集用户行为的重要洞察，或在将功能引入原生应用之前评估其成功与否。

随着移动浏览器在利用处理能力方面取得越来越大的进步，以及新的前端技术承诺提供类似应用的体验，现代化我们在移动端的求职体验是一个无需多虑的决定。

技术挑战

招聘中心建立在Vue.JS之上，它恰好拥有丰富的库生态系统。我们进入这个求职项目时就知道，未来我们的目标应该是通过一个连贯、响应式的网页体验来服务整个招聘中心。

UI库

我们需要一个可扩展且灵活的组件库，能够容纳upGrad不断发展的设计系统——Hygge。选择理想库时的首要标准是可定制性、性能和社区支持。在深入研究了事件钩子、模板插槽和通用样式能力的可用性后，我们缩小了范围，聚焦在Vuetify和Quasar上。

这些库有着非常相似的核心理念和组件覆盖范围。考虑到这一点，我们尝试了一个真实世界的概念验证对决，在两个非常真实的测试中尝试实现设计提供的屏幕。在根据一组选定的指标（包括开发便利性、生产包大小、响应式设计覆盖范围等）对两者进行比较后，我们最终选择了Quasar！

我们为这次发布尝试的另一个“首次”是使用主题中性组件，并通过迭代演进使其成为我们自己的。这使我们能够更快地将产品带给用户，发展我们的组件库，并建立团队间共享的流程，同时也确保其他团队可以转向新的设计系统。

为什么选择UI库？ UI库允许快速开发样式一致的UI组件，这些组件随后可以在团队间共享。除了响应式之外，这些组件构建得可以跨浏览器兼容，同时让开发者不必担心可访问性问题。组件还统一了我们向组件传入和存储数据的方式。

显而易见的缺点是初始学习曲线有点陡峭，但损失的时间很容易通过质量保证任何自定义UI组件所需的额外时间来弥补。深入一点看，可能存在一个反对组件库的论点，即自定义UI库将是臃肿和过度定制的现成组件的一个更精简的替代方案。虽然这种担忧是合理的，但在现实中，我们能够通过几十行CSS全局定制组件以满足我们的设计需求。

在将列表缩小到仅剩2个库后，我们选择了Quasar而不是Vuetify，以下是我们如何客观评估它的。

Vue 3 支持 Vue 3带来了一些以性能为中心的主要功能，我们绝对不想错过。虽然Vuetify和Quasar都有支持Vue 3的详细路线图，但我们觉得使用Quasar进行转换会稍微容易一些，因为它承诺反向兼容性。话虽如此，我们确实很喜欢Vuetify在Notion上有一个高度组织的路线图。

对安全的重视 当你第一次查看Quasar页面上的部分时，真正突出的是安全选项卡！它包含了一套令人惊讶的详尽的安全“要做什么”、“不要做什么”以及每个最易受攻击组件的限制。最重要的是，一些组件带有内置的清理功能，非常方便！

核心理念 Quasar在正式发布之前，最初是一个专注于构建混合应用和Electron应用的移动优先框架。然后随着它扩展到包括桌面网页应用，它很快获得了关注。

开发体验 文档和易用性 在开发大规模网页体验时，任何库的文档方面对于按时交付高质量代码都起着巨大作用。乍一看，Vuetify呈现良好的文档，加上相对较低的入门门槛，使其成为明显的热门选择。然而，一旦我们开始深入研究更复杂的用例，Quasar才开始真正发光。

样式设计 两个库中的组件样式设计同样容易。Quasar有一个带有--inner前缀的自定义类，可以作为钩子来创建自定义样式。它还有基于元素状态改变样式的修饰符。（这在如下所示的情况下特别有用，其中输入元素在DOM树中的位置远低于控制样式的元素。）

灵活性 两个库的核心组件覆盖范围非常相似。然而，Quasar在扩展组件（stepper、timeline等）方面略有优势。然后我们开始分析所有核心组件的可定制属性（props）和插槽（slots）等的数量，我们发现Quasar的可定制性明显高于Vuetify。

组件库的灵活性对我们来说非常重要，因为它能让我们更快地编写代码和测试，并更快地将功能投入生产。此外，如果upGrad的所有Vue代码仓库都转向一个单一的库，那么共享捆绑了设置的现成组件将比共享一个具有深度链接依赖关系的自定义编写组件更容易。

让我们看看我们如何评估灵活性——

当我们第一次查看搜索栏的功能时，似乎我们需要从头开始构建一个组件来应对独特的用例。

搜索栏有3种状态——最近搜索、搜索建议和自定义搜索。虽然最近搜索的实现很简单，但后两种情况作用于搜索栏中存在的所有标签以及未标记的输入。

Vuetify和Quasar中最接近搜索栏功能的组件分别是v-combobox和q-select。查看v-combobox的API，没有内置的方式来访问未标记的输入值。

下面的例子给出了一个概念，说明定制组件行为以适应复杂用例是多么容易。

TypeScript 发布的另一个方面是转向TypeScript。直接的优势是IDE自动完成和静态类型检查。定义良好的类型使新开发者更容易理解代码（这在团队间共享组件时尤其有用）。对我们来说最大的权衡是增加了学习曲线。从长远来看，我们预计生产力会有轻微下降。

发布过程

我们将发布分为两部分，一部分针对桌面端，另一部分针对移动网页。我们首先在桌面端发布中为响应式设计奠定基础。然而，我们使用了一个条件标志来在生产环境中隐藏移动版本。第二个带来移动响应式的发布是以一种谨慎的方式编写的，确保之前测试过的代码大部分未被触动。

桌面端发布上线后，我们迅速回到工作中（当然，在短暂休息庆祝之后 🍻）。我们以移动优先的视角重新审视了交互、触摸目标和间距等关键因素，并在使用BrowserStack进行广泛的开发测试后，将其移交给QA。

未来展望

我们有一系列功能，将改善在移动设备上访问招聘中心的学习者的普遍易用性。我们专注于提高页面速度性能，并将更多桌面端功能带到移动端。实现全PWA（渐进式Web应用）是我们TODO列表上的下一个目标。PWA将为后台处理和推送通知打开大门，这将使我们向前迈进一步，为每个人带来世界级的学习体验。

请访问upGrad.com查看我们完全在线的课程！如果你希望与我们永远充满热情的团队一起工作，请查看我们的招聘页面。我们一直在寻找有抱负、有才华的人！

贡献者： Adarsh Sosale