感觉自己有点狂，居然敢在自己的文章中说这是最佳实践。不过有人不是说了吗，牛皮还是要吹的，万一实现了呢？
接下来公司的项目，就是纯粹的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
网友评论