关于Angular，开发人员经常忽视的9个想法

全文共3696字，预计学习时长11分钟

图源：Unsplash

Angular已经出现有段时间了，但很多人仍然在通过扩展应用程序来满足需求。

于是乎，热心市民小芯这次通过总结过去几年为客户使用Angular应用的经验，为大家列出了9个经常被忽视的想法。

 

这些想法最终实现模式可以帮助提高最终产品的质量。

 

斯、斯国一（小芯自说自捧中）

 

1. 创建组件库

 

将组件或指令转换为库并不是每天都要考虑的事情——在一般的系统中对其也没有足够的讨论——但应该在下一个应用程序中考虑它。

 

在应用程序开发领域，有些事情会反复出现。比如注册表单、登录模式或购物车系统。不管什么事，如果在日常生活中遇到过，那么就很有可能最终对其进行编码。

 

将组件转换为库时，就是正在为可重用部分的系统做出贡献，这些可重用部分是与更改隔离开的，并且可以加速团队的整体工作流。

 

因为组件库是可以跨项目共享的代码资产，也是具有维护更新和更改的集中方法。

 

例如，可能有一个购物车组件库，运用于网络应用程序、Angular / Ionic和zhendui客户服务的后端门户。无需手动更新组件集，只需编写库的更新版本并推出发行版即可。

图源：codecondo

2. 生产部署

 

有没有发现自己的Angular应用程序在实际场景中加载速度很慢，尽管它被缩小了?

 

Angular中的budgets可以设置最终编译代码的最大规模。按照设计，Angular在开发环境中运行速度非常快，但所有东西看起来都在以极快的速度运行，因为它们都是在机器上运行的。

 

然而，一个未编译的Angular应用程序的准系统已经在3.9mb左右运行了。一旦添加更多代码，它会变得更大……

 

规模变大的主要原因是所使用的有效的库的数量。当使用构建命令运行--stats-json标记时，可以看到最终应用程序大小。

 

3. 微前端可以让你在大型项目中保持清醒

 

微前端就像是科学怪人的孩子，但当有多个遗留单元需要处理时，它可以节省大量时间。

 

有时，一个全新的过渡是不可能的，而摆脱旧前端唯一方法就是采用微前端，将多个应用程序在一个容器页面中运行。

 

采用微前端方法时，可以清楚地将大型项目划分为彼此独立的、小的可执行部分。后端成为中心焦点，在应用程序的不同部分之间存储和共享数据。可能不得不使用事件监听器——但它肯定会集中存储和处理数据，将传统的后端任务带回其原始空间。

 

应用程序开发人员普遍有一个新习惯，那就是让前端来处理，尽可能减少后端工作。然而，这可能会导致安全漏洞。前端应该仅限于数据的可视化和实现，而不是实际的数据处理，这与首次筛选验证不同。

 

4. 自定义指令并非不好

 

Angular中的自定义指令还没有得到充分讨论。

 

通常的理解是，组件是模块化的部件，它们组合在一起形成应用程序。然而，如果将这种想法修改为指令，将其作为主要的构建模块之一，并将组件作为将它们粘在一起的粘合剂，那么真正的可重用性的概念将增加两倍。

 

这是因为在创建Angular快速应用程序时，通常的流程教程并不从自定义指令开始。然而，对于需要将功能与自定义特性明确分离的大型应用程序来说，自定义指令是非常方便的。

 

 

组件的目的是无论如何都要将所有东西组合在一起。数据的处理和操作应该位于服务器层面（这不仅仅局限于http对API的调用）。

 

自定义指令可以在整个代码库中共享，以减少重复代码，并且可以帮助创建能够快速适应变化的解构应用程序。如果需要创建新视图，可以将各个部分放在一起，而不是重新编写所有代码。

 

5. 集中数据存储

 

RxJS非常重要。虽然轻松访问状态是件好事，但是当涉及到的事情并非唾手可得时，事情很快就会变得混乱。

 

随着应用程序的增长，必须了解的状态数量也随之增长。尽管较小的应用程序在本地化状态管理方面很好用，但集中化的方法可以将所有内容都放在一起，并可以防止异常的回流。

 

是的，回流确实会发生——开始情况似乎是合乎逻辑的，直到应用程序的某些部分开始无法正常进行处理，因为这里的状态层次结构有点混乱。当子组件开始覆盖父组件时，就会开始出现逻辑混乱。

 

集中的数据流意味着状态和更改保持平稳——没有侧分支来偏离主流。每次更改都在一个没有任何偏差的循环中进行——这使得应用程序开发过程具有很高的可预测性，从而也会对同行编写的代码产生特定的期望。

 

RxJs实现的集中化流程加强了标准化。如果一切都是标准的，这意味着每个人的编码输出都在同一页面上。

图源：tuxi

6. 明确域和边界

 

Angular新手最常犯的一个最大错误就是一头扎进去，先写代码，再修正。在职业生涯中，开发人员都曾犯过这样的错误——即使不是使用Angular。

 

然而，随着经验日益丰富，不难发现好的架构和规划可以大大节省开发时间。

 

如何才能做到这一点呢？通过明确域和边界。

 

围绕不同的域来构建Angular应用，比如逻辑域、理论域和功能域。

 

然而域是什么呢？

 

域是一组本质上相似并属于特定类别的思想的集合。这些域的边界能有助于确定特定的特征或功能是否适合特定的分类。

 

不要只是按原样编写Angular程序。通过弄清楚事物应该如何分组，添加一些结构，从而确定组件、数据流和指令最终如何相互关联。

 

7. 组织域的方法

 

如前所述，有三种常见的方法来组织域——逻辑的、理论的和功能的。虽然它们看起来像是同一事物的变体，但由于它们让人想起应用程序的方式，其实它们并不是。

 

下面举一个逻辑域的例子。

 

当基于逻辑域对Angular应用的各个部分进行分组时，其实是在基于业务逻辑对所有内容进行分组。老板可能有特定的方式来展示价格表，所以要把所有与定价有关的内容都放在一个树状结构中。

 

但是，如果要采用理论方法，是基于预期行为来定位应用程序的组织。因此，与其将老板的定价方法归为一个域，不如根据定价最常使用的域来划分。

 

对于功能性方法，需要查看一组特定的功能，并确定它们是否适合基于功能的分组。功能性方法是逻辑和理论之间的平衡——最终部署的结构可能会随着应用程序中添加更多的特性而改变。

 

图源：Unsplash

8. 如何构建CSS

 

当谈到Angular开发时，CSS是大多数人最不愿考虑的东西。但是，它与应用程序的表示层联系紧密。它通常决定用户的最终体验以及他们与应用程序的交互方式。

 

虽然很容易将一些CSS放入由CLI生成的关联文件中，但是在可维护性方面，这可能会导致进一步的问题。接着开发人员做的就是抛弃!important声明让事情看起来更好。

 

除非永远不实现这些，否则如果实现了，一定会在下一次迭代中崩溃。

 

构建CSS的方式和构建Angular应用程序的方式一样重要。如果以同样的方式来处理CSS，找出哪些组件是可重用的，以及哪些类应该位于代码中的什么位置，然后处理表示层，这可以让开发人员正确地创建自定义解决方案，这应该是提上日程的第一件事,而不是事后才想起来。

 

当把创建CSS的过程和创建Angular代码的过程分开时，就能看到这两者是如何恰当地结合在一起的，会看到重复的元素，而不是忙忙碌碌地创建所有东西。

9. 灵活性越大越有用

 

Angular比许多外部人士意识到的要灵活得多。虽然该框架确实提供了预定的编写方式，但还是可以自由随意地构建自己的应用程序。

 

理论上，所有逻辑、外部数据的调用和进程都可以放在组件中。但是可以这么做并不意味着应该这么做。也许可以将其放在单个服务中，并将其导入到每个可能的组件中。

 

这些通常只是缺乏编程经验和对Angular工作原理缺乏理解的表现。是的，代码可能会有效，但从长远来看它不会扩展——不是因为框架本身，而是因为它被利用的方式。

 

学习Angular中常见的模式——比如中央状态存储、清晰的分离域以及如何使用组件指令——都可以用来应对糟糕的代码。

 

结语

 

这9点建议只是启示大家如何从长远角度思考更好地改善Angular代码。

 

它们是用来重构Angular代码的技术。

 

当事情失败时，退后一步，看看组织代码的方式，而不是一直分析框架。也许低效和模式在一开始是有意义的，但当添加更多部分时，则被证明是无效的。特定的项目做得越多，就越了解它是如何工作的——更能看到其不好的部分。

 

重构不是罪过。相反，应该养成这样做的习惯。重构不仅仅是删除代码，或是查看几个月前写的代码，然后惊恐地摇头。它是让程序员盘点目前的情况，找出哪部分可以做得更好，并付诸实施。

 

Angular既优秀又可靠，但只有思维和将思维转换成代码的行为同样优秀而可靠时，它才能发挥它本来的实力。

 

加油吧，米娜桑~

 

 

 

留言 点赞 关注

我们一起分享AI学习与发展的干货
欢迎关注全平台AI垂类自媒体 “读芯术”

（添加小编微信：dxsxbb，加入读者圈，一起讨论最新鲜的人工智能科技哦～）