URL Shorteners 是我们用来使链接比实际更短的工具。 使用 URL Shortener，您可以将长链接（可能是注册表单或文章）转换为较短的版本。
在幕后，给定链接的长版本和短版本已存储在某个数据库中。 然后，当用户在浏览器中访问短链接时，URL Shortener 会将用户重定向到链接的长版本（实际内容所在的位置）。
当这些链接的长版本太长而无法使用时，通常使用来自 URL 缩短器的缩短链接。 在社交媒体上或在设计传单和广告时共享链接是 URL 缩短器的流行用途。
对于我的一个项目，我创建了一个个人 URL 缩短器。 我的目的是将它用于我写的文章或我制作的视频的链接。 我用了 Firebase 构建 URL 缩短器的后端。 具体来说，我使用 Firestore 数据库来存储任何给定链接的短版本和长版本。
要创建链接，我必须使用 Firebase 控制台。 这不是问题，但是对于高频率的编辑链接来说很麻烦。 用户体验 (UX) 并不理想。 现在我面临一个问题。 如何创建、编辑和删除链接？ 我需要为 URL 缩短器构建一个前端。 我需要一个网站。
在本文中，我们将回顾用于构建此前端的可用工具、决策选择以及影响其制作原因的因素。
问题陈述
项目要求是：
- 平台/架构. 编码过程的工程和结构。
- UI工具包. 用于 UI 各个部分的组件。
- 方便. 构建后端并不难，所以这个前端也不应该是。 我想要干净的代码和快速的开发。
第一选择：Angular
开始构建前端时会想到许多想法。 从广义上讲，我们可以将前端构建选项分为 3 个平台：
- 网站建设者——如 WordPress、Wix、Squarespace 等。
- Vanilla Building – 使用纯 HTML、CSS 和 JavaScript。
- JavaScript 框架——如 React、Vue、Angular 等。
根据我的经验，网站建设者提供的小部件、组件和模板的集合非常有限。 大多数网站建设者没有提供一种简单的方法来集成像 Firebase 这样的整个自定义后端。 虽然可以通过将这些部分连接在一起来构建令人印象深刻的网站，但我的项目的复杂程度可能超出了这些服务通常提供的程度。
使用无框架样式或香草是可能的。 然而，让我没有选择纯香草路线的决定因素是 Firebase JavaScript SDK 的最新非 CDN 版本（版本 9） 设计与安装通过 npm or yarn 并考虑到模块捆绑。
JavaScript 框架处理前端核心部分（如路由、后端链接等）以减少开发人员的工作量。 它们中有很多，选择使用哪个似乎是一个更难的选择。
有许多用于前端开发的 JavaScript 框架。 示例包括 Angular、React、Vue 等。
在可用的框架中，我最熟悉 Angular。 这是因为我在以前的项目中使用过它，例如：
- 合唱团卡罗尔测验：门户网站，测验参与者在两轮在线选择圣经章节的定时多项选择题中竞争。
- Genesys AE-FUNAI 社区：Genesys Campus Club AE-FUNAI（我的社区）成员报告他们的进展并分享他们的成就的自定义表格。
- 教程管理系统：学生和导师之间的简单会话管理仪表板。
这种熟悉程度使我能够快速使用 Angular 进行构建。 不应低估能够快速构建的能力。
我之所以选择 Angular，是因为它具有面向对象编程 (OOP) 的能力。 OOP 是一种编程范式，它更多地关注被管理的类、数据或状态，而不是像函数式编程那样关注控制数据的逻辑。 关注点分离是使用 OOP 的优势之一。 换句话说，OOP 允许封装。 它允许您将程序的各个方面限定为特定的域或类。
在 Angular 中，组件（及其生命周期方法）的范围为 TypeScript 类。 这让你想到了 OOP 方式。 OOP 的优势体现在 Angular 组件如何在 Angular 框架中充当可重用的 UI 单元。 这样你就可以将 Angular 组件看作是一个自给自足的实体，它仍然是整体的一部分。 这使得前端开发变得容易，因为前端应用程序的各个部分都可以限定为组件，因此可以在需要的地方使用。
我还选择了 Angular，因为它使用 TypeScript。 TypeScript 是具有类型化编程语言特性的 JavaScript。 在这种情况下键入意味着变量不能改变它在其整个生命周期中所持有的值的类型。 例如，保存字符串的变量在该程序中使用时不会突然保存数字。 打字提高了代码质量并减少了错误。
由于其类型系统，TypeScript 减少了调试 Angular 应用程序所花费的时间。 它为开发人员提供了体验，因为开发人员将有更多时间来构建前端应用程序。 对开发人员来说，调试也变得很容易。
请注意： 这里有更多关于使用 TypeScript 进行面向对象编程的内容
尽管如此，由于 Angular 的优势，Angular 应用程序是一个完整的设置。 它们自己处理重要的特性，比如捆绑 CSS 预处理器或 Angular 服务。 也就是说，在使用 Angular 时，您不需要单独配置每个库，Angular 会处理这个问题。
Angular 服务是 Angular 用来配置依赖注入的。 简单来说，依赖注入为应用程序提供了它需要运行的东西（依赖项），而应用程序不必关心依赖项是如何获得的。 我还选择了 Angular，因为它对服务的处理方式是开箱即用的。 因此，例如，Firebase 将自动提供给所有需要的 Angular 组件，而无需任何额外配置。
面向对象编程、TypeScript 和依赖注入的优势使 Angular 成为前端开发的首选。 再加上我已经熟悉 Angular，Angular 对于这个 URL 缩短器项目更方便。
关于 CSS-Tricks 的 Angular 文章 也是故事的一部分。 他们让我对使用 Angular 更有信心。
第二个决策选择：材料设计
选择 Angular 后，我的下一个任务是考虑如何处理用户界面 (UI)。
我可以忽略并改用香草 CSS，但为什么要重新发明轮子呢？ 毕竟，这会破坏使用 JavaScript 框架的原因——方便。
选择 UI 工具包后，似乎有很多选择。 仅举几例，可以使用 Bootstrap、Bulma、Semantic UI、Tailwind 等。每个工具包都有自己的规范和动机。
对于我的项目的用例，Material Design 领先。
最重要的因素之一是对 Angular 和 Material Design 的支持。 材料上有一个完整的 Angular 规范 material.angular.io （即作为 Angular 文档本身的子域）。
我选择了 Material Design，因为它专注于组件。 与其他 CSS 框架不同，它没有 CSS 实用程序类。 这没关系，因为我只想要一些组件工具包（按钮、图标、输入、侧边栏、小吃店等）。材质本身还添加了动画、波纹和阴影效果； 使其比其他库更方便。
此外，Angular Material 具有开箱即用的主题支持，在初始化 Angular Material 时，您可以选择为整个 Angular 应用程序选择预定义的主题或创建自定义主题。
为了方便起见，我在设置 Angular Material 时选择了深色主题。
第三个决策选择：反应形式
确定了框架和工具包后，我将注意力转向了 URL 缩短器最重要的功能之一。 URL 缩短器前端的核心是用于创建和更新链接的表单。
让我们将此表单称为链接编辑器。 链接编辑器表单只有两个输入，一个用于链接的简短版本，另一个用于简短版本将重定向到的完整 URL。
对于管理表单，Angular 提供了两种机制。 因此，您不必像在普通 HTML 和 JavaScript 中那样创建表单并处理其验证和提交，而是必须使用 Angular 提供的两种方式中的任何一种。 这两种方法是：
- 模板驱动的表单
- 反应形式
模板驱动的表单 顾名思义，涉及控制大部分 Angular 表单的 HTML（模板）代码。 当您的表单没有太多功能或仅用于一次性使用时，这种方法更可取。
反应形式另一方面，提供了一种模型驱动的方法来处理其值随时间变化的表单输入。 我需要响应式表单，因为它与我将在任何时间点用于编辑不同链接的表单相同。
请注意： 这里有更多关于使用 Reactive Forms 的材料。
此时，先前选择的好处开始发挥作用。 角材料有 form-field 成分。 这 form-field 将输入包装为组件，并在必要时提供动画、涟漪效果和错误消息。
所以我将它用于编辑器表单的两个输入。
第四种决策选择：角料底板和抽屉
最终决定涉及如何改善用户体验。 URL 缩短器需要其他功能，例如查看所有创建的链接及其分析。 这些功能需要屏幕上的空间，这需要我重新考虑是否有更好的解决方案来向用户显示链接编辑器表单。
如果用户当前不需要链接编辑器表单，则链接编辑器表单并不总是在视图中是有意义的。 这将为其他元素释放 UI 上的空间。
然而，将这种用户体验分成两个单独的页面会让人感觉很混乱。 相反，为了在需要时打开链接编辑器，我在页面上添加了一个浮动操作按钮来创建链接。 单击该按钮后，将在任何合适的 UI 组件中打开编辑器表单。
A 底片，顾名思义，是一个从屏幕底部打开的 UI 组件。 它具有用户可以使用的交互式内容。 它覆盖了移动屏幕的当前视图（但不会完全阻止它）。
如果用户将花费很长时间与其内容进行交互，则通常使用底部表格代替弹出窗口。 因此，底部表格非常适合在移动屏幕上打开编辑器。 但是，当屏幕很宽时，与底部页面进行交互是很困难的。 我需要一个不同的 UI 组件用于宽屏上的链接编辑器表单。
抽屉 在旁边开。 使用抽屉在宽屏幕上打开链接编辑器表单是首选选项。 抽屉对移动屏幕上的编辑器不利。 屏幕的宽度会相对较小，并且抽屉可能会完全挡住屏幕（这不是理想的 UX）。
我从 Material Design 中选择了这两个 UI 组件，以使表单具有一些响应效果。 因此，无论是在我的手机还是笔记本电脑上创建链接都将在合适的 UI 组件中完成。
在代码中，Angular 检查设备是否具有小屏幕宽度。 如果是这样，它会打开一个包含链接编辑器表单的底部工作表。 另一方面，如果屏幕很宽，Angular 会打开一个包含相同表单的抽屉。
使用这两个组件带来了轻微的并发症。 如果我的手机被旋转或者我的笔记本电脑的浏览器窗口的宽度被缩小，表单会在相反的 UI 组件上打开。 也就是说，它不会在笔记本电脑的抽屉中打开，而是在底页中打开（因为浏览器的宽度减小了）。
维护、面向未来、未来版本
当我想到迭代这个项目的机会时，我遇到了当前旨在支持单个管理员的用例的限制。 但通过身份验证和用户帐户，它可以支持其他用户管理链接和访问分析。
在这种情况下，上述组件的选择仍然是合适的。 链接编辑器在任何设备上都是响应式的，用户将获得良好的用户体验。
如果我必须重新做一遍，我想我会尝试香草方法。 完全无需任何辅助工具（如 Angular、Material 或 UI 组件）即可构建。 我会尝试在 HTML、CSS 和 JavaScript 中从头开始构建，看看我是否没有像我想的那样失去便利。
结论
你可以在 GitHub 上访问最终的 Angular 代码。
这是对我在开发项目时做出的一些主要选择的回顾。 当然，构建 URL 缩短器的前端还有更多工作要做。 但首先，这些 UI 组件使构建过程变得方便。 他们使链接编辑器表单具有响应性，并且在您的项目中可能对您有类似的用途（不一定是 URL 缩短器）。
您可以将各种库中的许多其他 UI 组件用于任何此类项目。 但与我的情况一样，如果方便是决定性因素，您将做出适合 UI 的正确决策选择。
最终，影响我决策的因素是了解我的项目需要什么、对以前项目中使用的工具的了解以及对时间限制的期望。 我过去的经历——成功和错误——也帮助了我。
干杯！
