哈喽,大家好!我是前端实验室的小师妹!
前俩天在知乎上看到这样一个提问。很多人这么认为前端本来就是按一个个网页天然解耦的,给每个前端工程师分几个页面,干就完了,再说了,现在不是有很多现成的框架吗?
其实不然,即使使用了相同的框架,最后的软件质量也可能是天差地别的。前端各种库丰富多彩,它们也是为了解决那个阶段的问题而出现的,更重要的是,结合项目实际,灵活运用随机应变。
今天给大家介绍一个简单、可扩展,探索React最佳实践,面向生产级的 React 应用架构 bulletproof-react
Bulletproof React
提供了一个简单、可扩展且功能强大的架构,用于构建生产就绪的 React 应用架构。旨在提供一种使用生态系统中最好的工具创建React应用程序的方法,并具有良好的项目结构,可以很好地扩展。
作者以项目实践从项目配置、风格指南、项目结构、接口层、状态管理等 13 个方面展示了如何以某种方式做一些事情,以实际方式解决应用程序的大多数实际问题,并帮助开发人员编写更好的应用程序。
我们来看看它的目录结构,大多数源代码都应该位于src
文件夹目录中
feature 是服务于某个业务模块的 components、models 以及 utils 等模块的组合,如果是没有具体业务属性相关的通用模块就放外面。
├── features # 项目特性功能
│ ├── {feature1}
│ └── {feature2}
features通过切割目录,可以按功能管理组件、API、Hooks等。也就是说,如果每个函数都有一个API,你可以灵活管理,有效隔离但可以供其他模块使用,通过入口点向其他功能公开不同的功能部分。
该特性的功能只能通过这种方式导入:
import {AwesomeComponent} from "@/features/awesome-feature"
而不是:
import {AwesomeComponent} from "@/features/awesome-feature/components/AwesomeComponent
这也可以在 ESLint 配置中进行配置,以禁止以后通过以下规则进行导入:
{
rules: {
'no-restricted-imports': [
'error',
{
patterns: ['@/features/*/*'],
},
],
// ...rest of the configuration
}
在编写 React 程序时,经常会有 provider 和 router设置,在该库中是这样设置的:App.tsx
providers
routes
非常简单。
import { AppProvider } from '@/providers/app';
import { AppRoutes } from '@/routes';
function App() {
return (
<AppProvider>
<AppRoutes />
</AppProvider>
);
}
export default App;
在客户端上处理身份验证并不意味着不应在服务器上处理它。事实上,保护服务器上的资源更为重要,但也应该在客户端上进行处理,以获得更好的用户体验。
比如我们在登录/注册期间,收到一个存储在应用程序中的令牌,然后在每个经过身份验证的请求上,将令牌与请求一起发送到标头中或通过cookie发送。
最安全的选择就是将令牌存储在应用状态中,但如果用户刷新应用,则其令牌将丢失。
这就是为什么令牌存储在cookie中而不是localStorage/sessionStorage中。
授权是确定是否允许用户访问资源的过程。
比如基于角色的访问控制(RBAC)限制用户的某些内容允许置顶角色访问、基于权限的访问控制(PBAC)用户的评论,只有评论的作者才能删除它。
还有如何做状态管理、如何设计API接口层、如何处理错误、如何优雅的配置项目等等,作者从 13 个方面推荐了比较好的方案,目标就是展示以实际方式解决应用程序的大多数实际问题,并帮助开发人员编写更好的应用程序。
不知道大家是否认可作者的观点,能提出不一样的观点,欢迎讨论~
点击下方卡片回复关键字 架构 获取项目地址
欢迎加入前端实验室读者交流群,群里有不少技术大神,不定时会分享一些技术要点,更有一些资源收藏爱好者会分享一些优质的学习资料。吃瓜、摸鱼、白嫖技术就等你了~
进群方式:在下方公众号后台,回复111
,按提示操作即可进群。
如果该文章对你有帮助,那么就点击右下角的 [点赞]「在看」,给一个小小的鼓励吧~