React Native类组件少量全局数据选AsyncStorage还是Context合适？

当前方案可行性判断 #

你目前每个组件单独从AsyncStorage拉取全局数据的做法，在极小项目、全局数据几乎不会变动的前提下是可以跑通的，但存在三个明显的弊端：

• 重复冗余代码：每个用到用户ID、订阅信息的组件都要写一遍异步读取、加载态处理、异常捕获的逻辑，后续如果要修改存储字段规则，需要逐个改所有组件的拉取逻辑，维护成本极高
• 不必要的性能开销：AsyncStorage的底层是本地IO读写，重复读取相同的静态数据属于无意义的资源消耗
• 状态同步困难：如果全局数据（比如订阅状态）在某一处发生了修改，其他已经完成拉取的组件无法自动感知到更新，需要额外做事件通知、主动重新拉取，非常容易出现数据不一致的BUG

是否要改用Context Provider #

首先明确：Context完全支持Class组件，不需要你提前把组件改成函数组件，你担心的转换成本问题不存在。
Class组件使用Context有两种成熟方式：

1. 给组件添加静态属性contextType绑定你定义的全局Context，直接通过this.context就能拿到全局数据，写法非常简单
2. 在JSX中套一层Context的Consumer组件，通过render props的方式获取全局数据

Context的改造工作量远低于你的预期，合理的改造逻辑是把AsyncStorage和Context结合用，两者并不冲突：

1. 定义一个全局Context，声明你需要共享的用户ID、订阅信息等字段
2. 在根组件的Provider中，启动APP时一次性从AsyncStorage拉取所有全局数据存入Provider的state中
3. 后续如果需要修改全局数据，统一在Provider中封装方法：同时更新Provider的state + 写入AsyncStorage，一步完成状态同步和持久化
4. 需要用到全局数据的组件，只要绑定Context就能直接取数，不用再单独写AsyncStorage的拉取逻辑

这种方案既保留了AsyncStorage的持久化能力，又解决了重复代码、状态同步的问题，长期来看收益远高于你现在的方案。

折中过渡方案 #

如果你当下实在不想调整架构，也可以先把AsyncStorage的读写逻辑封装成独立的工具类，比如把拉取用户ID、订阅信息的逻辑统一封装成GlobalStorage.getUserId()、GlobalStorage.getSubscriptionInfo()这类公共方法，至少先解决重复代码的问题，后续要改Context的时候也只要修改工具类的内部实现，不需要改动组件内的调用代码。

内容的提问来源于stack exchange，提问作者DanielN43