感觉自己有点狂,居然敢在自己的文章中说这是最佳实践。不过有人不是说了吗,牛皮还是要吹的,万一实现了呢?
接下来公司的项目,就是纯粹的RN项目,从这个项目开始,做一些最佳实践的总结,我想是个不错的开始。
今天搭建了windows的开发环境,不是特别顺利,主要可能是资源被墙的原因,导致安装出错,或者安装缓慢。如果后面我想摸索了,可以专门尝试下,看看到底哪些资源需要翻墙,如果不翻墙该怎么解决的文章。
开发RN项目,首选还是MAC,毕竟跨平台,iOS也是不能少的。我前面都是用的Mac,想熟悉下windows,所以……
扯远了,其实也还好,如果出一篇开发环境该安装哪些工具和插件,也算是最佳实践的一部分吧[/狗头]。
下面列出【我以为】的最佳实践
集成Typescript
使用npx react-native init myrnprojectname --template react-native-template-typescript
初始化项目,因为会自动集成typescript到项目中。
原因:
为新建的项目创建git仓库
原因:
使用module别名,减缩导入module的长度
原因:
Using Custom Path Aliases with TypeScript
babel-plugin-module-resolver
使用Fastlane自动化打包、上传、发布
原因:
使用文件夹的方式组织组件
在接触 react-native 开发时,基本上看到的例子,都是将组件实现和样式写在同一个文件中。这种方式将相关实现集中在一起,但是同时也让它们糅合在一起,反而又不便于管理。
我喜欢用 typescrit 的方式写 react-native 项目。那么在创建一个组件时,我通常需要些组件、样式、限定props 和 state 的类型。如果写在一个文件中,有很大的概率让这个文件变得非常臃肿。
我这里说的“文件夹的方式组织组件”,就是想保持组件集中实现的同时,又能保证组件内各部分的相对独立。
比如我想创建一个SearchBar,我可以使用以下结构来定义:
- SearchBar
- index.tsx (组件渲染)
- styles.tsx (样式)
- types.tsx (类型)
以上定义乍一看还麻烦了,你试想下如果我们有一个复杂的组件,其实可以分成上、中、下三部分再组合在一起,然后按照“文件夹”的方式,将它们组织成如下结构:
- ComplexComponent
- index.tsx
- Top.tsx
- Middle.tsx
- Bottom.tsx
- styles
- index.tsx
- top.tsx
- middle.tsx
- bottom.tsx
- types
- index.tsx
- top.tsx
- middle.tsx
- bottom.tsx
上面的结构有个明显的好处,所有关于 ComplexComponent
的信息都在它所在的文件夹中,集中管理。内部组件、样式和类型又各司其职,调理清晰。即便有更复杂的组件,我们也可以用这种方式来扩展。
想必你会说这样写太繁琐,但是我想说的是,效率固然重要,代码可读性、可维护性也同样重要。不要只图一时之快。
使用Axios做网络请求,使用Axios拦截器
- axios-logger :轻松拦截请求、响应日志,并输出到控制台;
将iOS/Android原生依赖库封装成本地React Native Module
方便升级和代码复用
发布APP时移除console.log
babel-plugin-transform-remove-console