革新职业中心的求职搜索体验

我们如何快速构建并发布了职业中心全新的、移动友好的职位搜索体验。

前端开发者的一个轻度恐怖噩梦，就是听到那个令人生畏的问题——“我们要为移动网页发布这个吗？”——得到肯定的回答。你首先会想这会如何影响预估时间…然后是测试…字体大小…性能…你的头开始眩晕，突然注意到视线是如何变得一片漆黑…

不久前，upGrad 负责职业中心的几位开发者就遭遇了类似的情况。我们的任务是将这个流畅、革新后的职位体验带到移动网页上。

移动网页——为何它并未消亡

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

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

随着移动浏览器在利用处理能力方面取得越来越大的进步，以及新的前端技术承诺提供类似应用般的体验，我们在移动端现代化职位体验就成了理所当然的事。

新旧职位体验对比

技术挑战

职业中心基于 Vue.JS 构建，它恰好拥有丰富的库生态系统。我们在开始职位项目时就明确，未来应该致力于通过一个连贯的、响应式的网页体验来服务整个职业中心。

UI 库

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

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

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

为何选择 UI 库？

UI 库允许快速开发风格一致的 UI 组件，这些组件随后可以在团队间共享。除了具有响应性，这些组件还构建得能在不同浏览器间兼容，同时让开发者无需担心可访问性问题。组件还统一了我们向组件提供数据以及从组件存储数据的方式。

立即可见的缺点是初始学习曲线有点陡峭，但损失的时间很容易在 QA 任何自定义 UI 组件所需的额外时间中得到弥补。再深入一点，可能有一个反对组件库的论点，即自定义 UI 库会是臃肿且过度定制化的现成组件的更精简替代方案。虽然这个顾虑是合理的，但在现实世界中，我们能够通过几十行 CSS 全局定制组件以满足我们的设计需求。

在将我们的名单缩小到只剩 2 个库之后，我们选择了 Quasar 而非 Vuetify，以下是我们如何客观地评估它。

Vue 3 支持

Vue 3 带来了一些围绕性能的重大功能，我们肯定不想错过。虽然 Vuetify 和 Quasar 都有支持 vue3 的详细路线图，但我们觉得使用 Quasar 进行迁移会稍微容易一些，因为它承诺反向兼容性。话虽如此，我们确实很喜欢 Vuetify 在 Notion 上组织良好的路线图。

对安全的强调

当你第一次查看 Quasar 页面上的部分时，真正引人注目的是安全选项卡！它包含了一组详尽得出乎意料的安全“要”与“不要”以及每个最常见易受攻击组件的限制。最重要的是，一些组件带有内置的清理功能，非常方便！

核心理念

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

开发体验

文档和易用性

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

样式化

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

灵活性

两个库的核心组件覆盖范围非常相似。然而，Quasar 在扩展组件（步进器、时间线等）方面略有优势。然后，当我们开始分析所有核心组件的可定制属性和插槽等的数量时，我们发现 Quasar 比 Vuetify 的可定制性要高得多。

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

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

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

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

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

下面的示例让你了解，为适应复杂用例而自定义组件行为是多么容易。

Typescript

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

发布

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

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

未来范围

我们有一系列功能，旨在改善通过移动设备访问职业中心的学习者的一般易用性。我们专注于提高页面速度性能，并将更多桌面功能引入移动端。全面转向 PWA（渐进式网页应用） 是我们待办事项清单上的下一项。PWA 将为后台处理和推送通知打开大门，这将使我们朝着为所有人带来世界一流学习体验的目标迈进一步。

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

贡献者： Adarsh Sosale