如何优雅的搭建一个强大的前端项目架构？！

哈喽，大家好！我是前端实验室的小师妹!

前俩天在知乎上看到这样一个提问。很多人这么认为前端本来就是按一个个网页天然解耦的，给每个前端工程师分几个页面，干就完了，再说了，现在不是有很多现成的框架吗？

其实不然，即使使用了相同的框架，最后的软件质量也可能是天差地别的。前端各种库丰富多彩，它们也是为了解决那个阶段的问题而出现的，更重要的是，结合项目实际，灵活运用随机应变。

今天给大家介绍一个简单、可扩展，探索React最佳实践，面向生产级的 React 应用架构 bulletproof-react

bulletproof-react

Bulletproof React 提供了一个简单、可扩展且功能强大的架构，用于构建生产就绪的 React 应用架构。旨在提供一种使用生态系统中最好的工具创建React应用程序的方法，并具有良好的项目结构，可以很好地扩展。

作者以项目实践从项目配置、风格指南、项目结构、接口层、状态管理等 13 个方面展示了如何以某种方式做一些事情，以实际方式解决应用程序的大多数实际问题，并帮助开发人员编写更好的应用程序。

目录结构

我们来看看它的目录结构，大多数源代码都应该位于src文件夹目录中

features目录

feature 是服务于某个业务模块的 components、models 以及 utils 等模块的组合，如果是没有具体业务属性相关的通用模块就放外面。

代码语言：javascript复制

    ├── features # 项目特性功能
    │   ├── {feature1}
    │   └── {feature2}

features通过切割目录，可以按功能管理组件、API、Hooks等。也就是说，如果每个函数都有一个API，你可以灵活管理，有效隔离但可以供其他模块使用，通过入口点向其他功能公开不同的功能部分。

该特性的功能只能通过这种方式导入：

代码语言：javascript复制

import {AwesomeComponent} from "@/features/awesome-feature"

而不是：

代码语言：javascript复制

import {AwesomeComponent} from "@/features/awesome-feature/components/AwesomeComponent

这也可以在 ESLint 配置中进行配置，以禁止以后通过以下规则进行导入：

代码语言：javascript复制

{
    rules: {
        'no-restricted-imports': [
            'error',
            {
                patterns: ['@/features/*/*'],
            },
        ],

    // ...rest of the configuration
}

provider 和 routes

在编写 React 程序时，经常会有 provider 和 router设置，在该库中是这样设置的：App.tsx providers routes 非常简单。

代码语言：javascript复制

import { AppProvider } from '@/providers/app';
import { AppRoutes } from '@/routes';

function App() {
  return (
    <AppProvider>
      <AppRoutes />
    </AppProvider>
  );
}

export default App;