Revamping the Job Search Experience on Career Centre

一位前端开发者最轻微的噩梦，就是听到一个令人生畏的问题——“我们为移动网页发布这个吗？”——答案是“是的”。你首先会想这将对预估时间产生什么影响……然后是测试……字体大小……性能……当你突然注意到视线开始变暗时，你的头开始发晕……

不久之前，upGrad负责职业中心的几位开发人员也经历了类似的事件。我们的任务是将这个时尚、经过改进的职位搜索体验带到移动网页上。

mWeb——为何它并未过时

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

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

随着移动浏览器在利用处理能力方面迈出越来越大的步伐，以及新的前端技术承诺提供类似应用的体验，将我们的职位搜索体验在移动端现代化是理所当然的。

技术挑战

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

UI库

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

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

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

为何选择UI库？

UI库允许快速开发风格一致的UI组件，之后可以在团队间共享。除了响应式之外，这些组件构建时考虑了跨浏览器兼容性，同时让开发人员无需担心可访问性。组件还统一了我们在组件之间传递和存储数据的方式。

显而易见的缺点是初始学习曲线有点陡峭，但损失的时间很容易在QA任何自定义UI组件所需的额外时间中得到补偿。再深入一点，反对组件库的一个可能论点是，自定义UI库将是比臃肿且过度定制的现成组件更精简的选择。虽然这种担忧是合理的，但在现实中，我们能够通过几十行CSS全局定制组件以满足我们的设计需求。

在将列表缩小到仅剩两个库后，我们选择了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（渐进式网络应用）是我们待办事项清单上的下一步。PWA将为后台处理和推送通知打开大门，这将使我们朝着为所有人带来世界级学习体验的目标又迈进一步。

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