来自其他语言和框架的模式可增强您的前端项目

我从事编程已有 12 年，使用过多种语言。其中包括C 、 C++ 、 Java 、 Python 、 C# ，最后是JavaScript 。每种语言或框架都有自己的规则。例如， Rust使用snake-case作为函数名。

然而，有一些规则、工具和模式是我逐渐理解的。我将这些合并到我的前端应用程序中。这些规则只会引起我更多的共鸣，并使编码过程更加顺畅。以下是我特别喜欢的一些：

函数式编程

我的第一个技巧来自 C，这是我学习的第一门语言。还记得我们以前用类编写 React吗？光想想就让人不寒而栗。当 React 切换到功能组件时，它不仅使代码更易于阅读，而且更易于测试。

它还更符合函数式编程的原则。

这种方法非常适用于前端框架，因为它们通常专注于创建可重用的代码片段。在前端开发中使用函数式编程对我理解这个概念以及构建新的前端功能一直是一个很有帮助的策略。

遵循函数式编程原则是我每个前端应用程序的必备条件。

如果您不熟悉函数式编程，我强烈建议您进一步探索它。这一点不在列表的开头是没有道理的。它可以为您的开发过程带来的好处是巨大的。

代码格式化程序

刚开始编程的时候，我并没有太注意代码格式化。我想这一切都始于大学，当时我在我的白色主题的酷CodeBlocks IDE上学习 C++。

回顾我 2016 年在 GitHub 上的旧代码，我可以看到我只使用空格进行格式化。我没有使用任何工具来自动处理这个问题。

现在，我意识到那是一个错误。如果你可以在你的项目中自动化某些东西，你绝对应该这样做。现在，我总是在每个项目开始时设置Prettier和ESLint 。如果你不想在这上面花很多时间，你可以使用像Airbnb那样的预制配置。

相信我，你不会后悔的！

哦，不要忘记在您的 IDE 中设置文件保存操作的自动格式化！

预提交操作

现在你有了很棒的格式化程序，让我们自动化它们吧！我不太记得我是什么时候开始使用预提交挂钩的，但它们对我的项目帮助很大。为什么在每次提交之前都可以自动格式化时手动格式化？ husky和lint-staged等工具使这种自动化成为可能。

文件名的烤肉串大小写

尽管Angular有很多粉丝和批评者，但我还是喜欢关注积极的一面。 Angular 通常是大公司和大型应用程序的首选。我认为在 Angular 中做出的许多决定都是为了让事情易于维护。

这就是为什么我决定在我所有的前端项目中使用 kebab-case。它提供了一些好处，例如：

• 简单：我不必担心是使用 pascal-case、camel-case 还是 snake-case（如果您愿意）。使用 kebab-case，只有一种选择。

• 一致性：如果您在团队中工作，采用像 kebab-case 这样的单一命名约定可以帮助确保每个人都在同一页面上，并且项目保持井井有条。不要忘记，您可以使用unicorn包通过 eslint 规则强制使用 kebab-case：

 'unicorn/filename-case': [ 'error', { case: 'kebabCase', }, ],

• 跨平台兼容性：不同的操作系统处理文件名的方式不同。例如，Windows 不关心大小写，但 Linux 关心。通过使用使用小写字母和连字符的 kebab-case，我避免了任何问题。

• 没有 git 问题：在 git 中将文件从小写重命名为大写存在问题。使用 kebab-case，我不必担心。

我喜欢保持简单。如果我能让我的生活更轻松，并从中得到一些好处，我会全力以赴。

为文件类型使用标签

我从 Angular 借用的另一件事是他们如何命名文件。 Angular 建议以反映文件功能和类型的方式命名文件。我发现它使我更容易导航和理解项目的结构。在 Angular 中，文件名通常由三部分组成：特性区域、文件的角色和文件类型。

例如， heroes.component.ts表明该文件是heroes功能的组件，并且是一个 TypeScript 文件。 heroes.service.ts是heroes的服务。

我不是services的忠实粉丝，但我对我的 React 组件使用了类似的结构。这是一个例子：

 my-component ├── my-component.component.tsx ├── my-component.type.ts ├── my-component.style.css ├── my-component.spec.tsx └── my-component.story.mdx

我也将这种模式用于我的挂钩和函数。这种模式还教会我将测试放在与其相关的文件旁边。

自动代码生成

我之前提到的模式非常有用，但我们可以通过自动化让它变得更好。 Angular CLI 让用户自动生成代码，我总是使用plop来做同样的事情。 Plop 的模板系统非常强大，但最重要的是，它节省了时间。

通过自动化，我不必花太多时间思考组件的基本结构。这个任务可以自动化，这让我可以专注于我真正想做的事情。

使用“域”

我不打算在这里详细解释domain是什么。如果你想了解更多，我推荐阅读这篇文章。现在，我正在与一个全栈开发人员团队合作，我们发现在我们的前端项目中拥有一个领域层非常有用。

这是我们放置所有主要类型和操作的地方。它在我们的应用程序中充当“真实来源”。

如果您想了解我如何处理我的应用程序中的“域”，您可以查看这篇文章。我在那里花了很多时间来描述这个话题。

测试你的架构

在我们使用Kotlin的工作中，我们曾经遇到一个问题，逻辑在多个层中混合在一起，比如使用在我们域内的存储库中定义的类型。从清洁架构的角度来看，这是不可行的，但每个人都会犯错误。

那是我们发现ArchUnit的时候，它是一种用于对我们的架构进行单元测试的工具。它基本上检查我们是否正确地遵守我们的架构。

如果您要维护特定的体系结构，那么拥有一个工具来检查它是否在某个时候没有被破坏会很有用。像dependency-cruiser这样的工具在这方面可能是无价的。

这就是我用于增强前端项目的其他语言和框架的基本模式列表。我希望这些信息对您有所帮助，并且这些策略中至少有一个启发了您在自己的工作中实施它！