介绍 前端开发人员经常面临与应用程序架构相关的问题。它需要使用一种能够轻松扩展并在应用程序模块之间提供松耦合和高内聚性的架构。 本文讨论功能切片设计架构，因为在我看来，它是可用选项中最好的。它还探讨了 FSD 的思想以及该架构方法解决的问题。 我们将 FSD 与经典和模块化架构进行比较，并检查它们的优缺点。 首先，让我们区分三个概念：层、切片和段。 层数 层是顶级目录和应用程序分解的第一层。它们的数量有限（最多 7 层）并且是标准化的，尽管其中一些是可选的。 目前，分为以下几层： 每层都有自己的职责范围，并且以业务为导向。让我们分别考虑每一层。 app：这是应用程序逻辑初始化的地方。提供者、路由器、全局样式、全局类型声明等都在这里定义。它充当应用程序的入口点。 进程：该层处理跨多个页面的进程，例如多步骤注册。该层已被视为已弃用，但仍然偶尔会遇到。它是一个可选层。 页面：该层包括应用程序的页面。 小部件：这些是页面上使用的独立 UI 组件。 特点：这一层处理用户场景和承载业务价值的功能。比如点赞、写评论、给产品评分等。它是一个可选层。 实体：该层代表业务实体。这些实体可以包括用户、评论、评论等。它是一个可选层。 共享：该层包含不依赖于特定业务逻辑的可重用组件和实用程序。它包括UI套件、Axios配置、应用程序配置、不绑定业务逻辑的助手等。 这些层有助于组织代码库并促进模块化、可维护和可扩展的架构。 特征切片设计的关键特征之一是其层次结构。在此结构中，实体无法使用特征中的功能，因为特征在层次结构中处于较高位置。 同样，功能不能使用小部件或进程中的组件，因为上面的层只能使用下面的层。这样做是为了维持仅沿一个方向引导的线性流动。 层在层次结构中的位置越低，对其进行更改的风险就越大，因为它可能会在代码中的更多位置使用。例如，共享层中的UI套件用于功能层、小部件甚至页面层。 切片 在每一层中，都有子目录——切片——应用程序分解的第二层。在切片中，连接不是抽象事物，而是具体的业务实体。切片的主要目标是按代码的值对代码进行分组。 切片名称并不标准化，因为它们直接由项目的业务领域决定。例如，在照片库中，可能有照片、相册和图库等部分。社交网络需要帖子、用户和新闻源等切片。 密切相关的片段可以在结构上分组在一个目录中，但它们必须遵守与其他片段相同的隔离规则 - 不应对该目录中的代码进行共享访问。 段 每个切片由段组成。段有助于根据用途划分切片内的代码。根据团队的协议，段的组成和命名可能会发生变化。以下几段比较常用： api - 必要的服务器请求。 UI - 切片的 UI 组件。 模型 - 业务逻辑，即与状态的交互。例如，操作和选择器。 lib - 切片内使用的辅助功能。 config - 切片的必要配置，但config段很少遇到。 consts - 必要的常量。 公共API 每个切片和段都有一个公共 API。公共API由index.js或index.ts文件表示，它允许仅从切片或段中提取必要的功能到外部，并隔离不必要的功能。索引文件充当入口点。 公共 API 规则： 应用程序切片和段仅使用公共 API 索引文件中定义的切片的功能和组件。 未在公共 API 中定义的切片或段的内部部分被视为隔离的，并且仅在切片或段本身内开放供访问。 公共 API 简化了导入和导出的工作，因此在更改应用程序时，无需更改代码中各处的导入。 深入了解建筑 抽象和业务逻辑 层越高，与具体业务节点的联系越多，包含的业务逻辑也越多。层越低，层中的抽象性、可重用性和缺乏自治性就越多。 FSD如何解决这个问题？ 特征切片设计的任务之一是实现松耦合和高内聚。了解 FSD 如何实现这一结果非常重要。 在OOP中，这些问题早已通过 、 、 、 等概念来解决。这些概念确保了代码的隔离性、可重用性和多功能性，根据组件或功能的使用方式获得不同的结果。 多态 封装 继承 抽象 功能切片设计有助于在前端应用这些原则。 和 是通过层来实现的。由于较低层是抽象的，因此它们可以在较高层中重用，并且根据条件，组件或功能可以根据指定的参数或属性以不同的方式工作。 抽象 多态性 是通过Public API实现的，将不需要的东西以切片和段的方式与外部隔离。对切片内部段的访问受到限制，并且公共 API 是从切片或段访问功能和组件的唯一方法。 封装 也是通过层实现的，因为较高层可以重用较低层。 继承 与经典架构的比较 相信您已经多次接触过经典建筑。由于其简单性，大多数作者在教育文章和 YouTube 视频中使用它。古典建筑没有具体的标准。但是，经常可以看到以下格式： 经典架构有明显的缺点。最大的一个问题是，由于组件之间的隐式连接和模块混乱，项目变得难以维护。随着时间的推移，经典架构的缺点变得更加明显。项目发展的时间越长，应用程序架构就越变得难以理清。 经典架构适用于无需持续维护的小型项目或宠物项目。 功能切片设计凭借其概念和标准，可以防止经典架构的问题。 然而，使用 FSD 的开发人员的理解和技能水平应该高于使用经典架构时的理解和技能。通常，经验不足 2 年的开发人员没有听说过 FSD。 然而，在使用功能切片设计时，需要“现在”而不是“以后”解决问题。代码中的问题和与概念的偏差立即变得显而易见 与简单模块化架构的比较 简单的模块化架构有几个缺点： 有时不清楚将功能放入模块或组件的何处。 在另一个模块中使用模块时遇到困难。 存储业务实体的问题。 全局函数中的隐式依赖关系，导致结构错综复杂。 似乎在任何复杂或中等复杂的项目中，功能切片设计应该优先于简单的模块化架构。 FSD 解决了许多基本的架构问题，并且几乎没有缺点。 就简单性和开发速度而言，简单的模块化架构可能比 FSD 有优势。如果需要 MVP 或者正在开发一个短期项目，简单的模块化架构可能比 FSD 更合适。但在任何其他情况下，功能切片设计看起来更可取。 特征切片设计的潜力 FSD 是一种年轻的建筑方法论。然而，它已经被许多银行、金融科技、B2B、电子商务公司等所使用。以下是包含公司列表的 GitHub 问题的链接： 。 GitHub 问题 在发布本文时，包含 FSD 官方文档的 GitHub 存储库拥有超过 1.1k 颗星。该文档正在积极扩展，FSD 开发团队以及 Telegram 和 Discord 社区可以 24/7 全天候帮助人们解决与架构相关的问题。 这种架构的潜力受到高度重视，并且在全球大公司中广泛使用。如果采用得当，FSD 有潜力成为前端开发领域的主导架构解决方案。 架构的优点和缺点 优点 架构组件可以轻松替换、添加或删除 架构标准化 可扩展性 该方法独立于开发堆栈。 模块之间的受控和显式连接不会产生意外的副作用。 面向业务的架构方法。 缺点 与许多其他架构解决方案相比，进入门槛更高。 需要意识、团队文化和对理念的坚持。 挑战和问题需要立即解决，而不是稍后解决。代码问题和概念偏差立即可见。不过，这也可以被视为一个优势。 结论 功能切片设计是前端开发人员应该了解并能够使用的一个有趣且有价值的发现。 FSD 可以为团队提供灵活、标准化、可扩展的架构和开发文化。然而，利用该方法的积极方面需要团队内的知识、意识和纪律。 FSD因其清晰的业务导向、实体定义、功能组成和应用程序的组件组成而在其他架构中脱颖而出。 您还可以独立探索项目中 FSD 使用示例和官方功能切片设计文档： 官方文档 例子。 GitHub 客户端 例子。耐克运动鞋和鞋类商店 例子。数独 这篇文章可能很长，但我希望您学到了一些新东西。我很感激您读完这篇文章。 如果您有任何想法或疑问，请随时发表评论！ 也发布 在这里

This story contains new, firsthand information uncovered by the writer.

The writer is smart, but don't just like, take their word for it. #DoYourOwnResearch before making any investment decisions or decisions regarding your health or security. (Do not regard any of this content as professional investment advice, or health advice)

This story will praise and/or roast a product, company, service, game, or anything else people like to review on the Internet.

最佳复杂前端架构：关于功能切片设计您需要了解什么

太長; 讀書

Yan Levin

STORY’S CREDIBILITY

Original Reporting

DYOR

Review

About Author

標籤

Languages

这篇文章刊登在...