React Native最佳实践

感觉自己有点狂,居然敢在自己的文章中说这是最佳实践。不过有人不是说了吗,牛皮还是要吹的,万一实现了呢?

接下来公司的项目,就是纯粹的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

将原生功能封装成Module并做成npm依赖库(本地或远程)

创建一个readme文件夹,在里面管理项目的账户信息、BUG修复、以及项目的注意事项……

集成CodePush,实现热更新功能

使用CI/CD工具,实现自动打包和发布安装包;Fastlane、Jenkins、Betaqr、蒲公英、Testflight;

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
平台声明:文章内容(如有图片或视频亦包括在内)由作者上传并发布,文章内容仅代表作者本人观点,简书系信息发布平台,仅提供信息存储服务。