URL缩短器是我们用来使链接比其实际长度更短的工具。使用URL缩短器，你可以将一个长的链接（也许是注册表或文章的链接）变成一个短的版本。
在幕后，一个给定链接的长版和短版已经存储在一些数据库中。然后，当用户在浏览器中访问短链接时，URL缩短器将把用户重定向到该链接的长版本（找到实际内容的地方）。
来自URL缩短器的缩短链接通常在这些链接的长版本太长而无法使用时使用。在社交媒体上分享链接，或在设计传单和广告时，是URL缩短器的一个普遍用途。
在我的一个项目中，我创建了一个个人URL缩短器。我的意图是用它来链接我写的文章或我做的视频。我使用Firebase来建立URL缩短器的后台，具体来说，我使用Firestore数据库来存储任何特定链接的长短版本。
为了创建链接，我不得不使用Firebase控制台。这不是一个问题，但对于编辑链接的高频率来说，它是很麻烦的。用户体验（UX）并不理想。现在我面临着一个问题。我怎样才能创建、编辑和删除链接？我需要为URL缩短器建立一个前端。我需要一个网站来做这件事。
在这篇文章中，我们将回顾用于建立这个前端的可用工具，决策选择，以及影响决策的因素。
问题陈述
项目的要求是。
- 平台/架构。编码过程的工程和结构。
- UI工具箱。用于用户界面的各个部分的组件。
- 方便性。建立后端并不困难，所以这个前端也不应该是这样。我想要干净的代码和快速的开发。
第一个决定选择。Angular
当开始构建一个前端时，很多想法会出现在脑海中。从广义上讲，我们可以将前端建设的选择分为3个平台。
- 网站建设者--如WordPress、Wix、Squarespace等。
- Vanilla Building - 使用普通的HTML、CSS和JavaScript。
- JavaScript框架--如React、Vue、Angular等。
根据我的经验，网站建设者提供的小工具、组件和模板的集合非常有限。大多数网站建设者并没有提供一个简单的方法来整合整个自定义的后台，比如Firebase。虽然有可能通过将这些部件连接在一起建立令人印象深刻的网站，但我的项目的复杂程度可能超出了这些服务通常提供的范围。
使用无框架风格或vanilla也是一种可能。然而，使我不选择纯vanilla路线的决定性因素是，Firebase JavaScript SDK的最新非CDN版本（第9版）在设计上考虑了通过npm 或yarn 和模块捆绑的安装。
JavaScript框架处理前端核心部分（如路由、后端链接等），以减少开发人员的工作。它们有很多，选择使用哪一个似乎是一个更难的选择。
有许多用于前端开发的JavaScript框架。例如Angular、React、Vue等。
在现有的框架中，我对Angular最熟悉了。这是因为我在以前的项目中使用过它，比如。
- Choir Carol Quiz:门户网站，测验参与者在网上进行两轮关于圣经章节的定时选择题的竞赛。
- Genesys AE-FUNAI社区。自定义表格，Genesys校园俱乐部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的支持。在material.angular.io （即作为Angular文档本身的一个子域）上，有一个完整的只针对Angular的Material规范。
我选择Material Design是因为它专注于组件。与其他CSS框架不同，它没有CSS实用类。这没有问题，因为我只想要一些组件套件（按钮、图标、输入、侧边栏、零食栏等）。Material还自己添加了动画、波纹和阴影效果；使它比其他库更方便。
此外，Angular Material有开箱即用的主题支持，在初始化Angular Material时，你可以选择为整个Angular应用选择一个预定义的主题或创建一个自定义的主题。
为了方便起见，我在设置Angular Material时选择了一个黑暗主题。
第三个决策选择。反应式表单
在决定了框架和工具包之后，我把注意力转向了URL缩短器的最重要的功能之一。URL缩短器前端的核心是用于创建和更新链接的表单。
让我们把这个表单称为链接编辑器。链接编辑器表单只有两个输入，一个是链接的短版本，另一个是短版本将重定向到的完整URL。
对于管理表单，Angular提供了两种机制。因此，你必须使用Angular提供的两种方法中的一种，而不是像在普通的HTML和JavaScript中那样创建一个表单并处理其验证和提交。这两种方法是。
- 模板驱动的表单
- 反应式表单
模板驱动的表单，顾名思义，涉及到HTML（模板）代码控制Angular表单的大部分内容。当你的表单做得不多或者是一次性使用的时候，这种方法是比较好的。
另一方面，反应式表单提供了一种模型驱动的方法来处理表单输入，其值随时间变化。我需要反应式表单，因为它是我在任何时候都会用来编辑不同的链接的同一个表单。
在这一点上，之前的选择的好处开始发挥出来。Angular Material有form-field 组件。form-field 将输入包裹成一个组件，并在必要时提供动画、波纹效果和错误信息。
所以我把它用于编辑器表单的两个输入。
第四个决策选择。角度材料底片和抽屉
最后的决定涉及如何改善用户体验。URL缩短器还需要其他功能，如查看所有创建的链接及其分析。这些功能需要屏幕上的空间，这就要求我重新思考是否有更好的解决方案来向用户显示链接编辑器的形式。
如果用户目前不需要链接编辑表单，那么链接编辑表单不总是显示在屏幕上是合理的。这将在用户界面上为其他元素腾出空间。
然而，将这种用户体验分割成两个独立的页面，让人感觉很不爽。相反，为了在需要时打开链接编辑器，我在页面上添加了一个用于创建链接的浮动动作按钮。当点击时，该按钮将导致编辑器的形式在任何适合的UI组件中被打开。
底层表单，顾名思义，是一个从屏幕底部打开的UI组件。它有互动的内容，用户可以操作它。它覆盖了移动屏幕的当前视图（但并不完全阻挡它）。
如果用户将花很长时间与他们的内容互动，底部表单通常被用来代替弹出式窗口。所以，底部表单很适合在移动屏幕上打开编辑器。然而，当屏幕很宽时，与底层表单进行交互是很困难的。我需要一个不同的UI组件用于宽屏幕上的链接编辑器表单。
抽屉从侧面打开。在宽屏幕上使用抽屉来打开链接编辑器表单是一个很好的选择。抽屉对于移动屏幕上的编辑器来说并不是好事。屏幕的宽度会比较小，抽屉可能会完全挡住屏幕（这不是一个理想的用户体验）。
我从Material Design中选择了这两个UI组件，让表单有一些响应的效果。因此，无论是在我的手机还是笔记本上创建链接都会在一个合适的UI组件中完成。
在代码中，Angular检查设备是否是小屏幕的宽度。如果是的话，它会打开一个包含链接编辑器表单的底层表单。另一方面，如果屏幕很宽，Angular会打开一个包含相同表单的抽屉。
使用这两个组件带来了一个小的复杂问题。如果我的手机旋转了，或者我的笔记本的浏览器窗口的宽度减少了，表单就会在相反的UI组件上打开。也就是说，它不是在笔记本电脑的抽屉里打开，而是在一个底层表单中打开（因为浏览器的宽度被缩小了）。
维护、面向未来、未来发布
当我想到对这个项目进行迭代的机会时，我遇到了目前设计为支持单一管理员的用例的限制。但通过认证和用户账户，它可以支持更多的用户管理链接和访问分析结果。
在这种情况下，上述组件的选择仍将是合适的。链接编辑器是响应式的，所以在任何设备上，用户都会有一个良好的用户体验。
如果让我重新做一遍，我想我会尝试虚无主义的方法。完全不使用任何帮助工具，如Angular、Material或UI组件来构建。我会尝试用HTML、CSS和JavaScript从头开始构建，看看我是否像我想象的那样没有失去便利。
总结
这是对我在开发项目时所作的一些主要选择的回顾。当然，建立一个URL缩短器的前端还有更多的东西。但首先，这些UI组件使构建过程更加方便。它们使链接编辑器的形式得到了响应，并且可以在你的项目中发挥类似的作用（不一定是URL缩短器）。
还有许多来自不同库的其他UI组件，你可以在任何这样的项目中使用。但就像我的情况一样，如果便利性是一个决定性的因素，你会做出适合于UI的正确决定选择。
最终，形成我的决定的是了解我的项目需要什么，我在以前的项目中使用过的工具的知识，以及对时间限制的期望。我过去的经验--成功和错误--也有助于指导我。
欢呼吧!
为什么我选择Angular来建立一个URL缩短器最初发表在CSS-Tricks上。你应该收到通讯。
