最近前端在对业务基础框架进行整理，在reactNative部分，我们发现非常常用且需要native支持的基础组件需求还是不少，而且大部分都急需解决跨平台的兼容性问题。从基础组件拆分的角度来将，当然我们的目标是将它们中与业务逻辑不相关的部分，完全node方式模块化，以第三方库的方式引入。经过对实际业务中使用reactNative的项目进行分析和抽象，我大概规划了一下需要单独抽出的库：
1.界面：toast与弹窗（在js层难以实现或易出bug），地图（功能复杂，代议）
2.功能：系统常量（js可用的环境变量），消息与通知，定位

当然从最简单的东西做起，应该本周飙了这么两个组件：

1.react-native-simple-toast

npm地址在此处
看名字就可知道，这是一个非常简单的toast库，主要目的是让ios拥有toast并且兼容安卓的api与表现，并且对于我们自己来说可以满足需求。所以简单。同样，对比已经存在的其它toast组件：
- 最出名的是react-native-toast，在实际使用中其实也是最优选择，它的安卓是使用的原声toast加上位置控制的api，ios使用的著名的toast控件也是我使用的这个。它的理念是增量api，将来rn自带的ToastAndroid的api增加到一个功能完整的高级toast上。
- 另外还有一个react-native-root-toast，它提供的功能更加高级，除了自定义位置还有事件监听和自定义界面。当然自习一看就知道这个toast是纯js实现的。为了避免和其它浮动控件冲突和各种奇怪的bug，我并不推荐。
回到我们这个组件，我们这个组件的技术方案选择和react-native-toast几乎一摸一样，唯一不同的是，我们使用的减法来设计的api，裁剪了第三方ios的toast的功能来保障其api和ToastAndroid对其。究其原因其实还是业务中的toast使用均以原有ToastAndroid为蓝本，因此对应的小而美的api即可满足所有需求了。

2.react-native-native-env

npm地址在此处
这个库看名字也很明显了，是为js提供native提供的环境变量的库，主要提供的是app名字啊版本啊和编译上下文环境的信息并且有别于platform。同时可以自己添加环境变量。在实际使用中，除了app的基本信息，手机的uuid，用户的uid和token，包括推送用的pushid等，都有可能添加到环境变量中去。总之这又是一个功能非常非常简单目的明确的库。继续对比起他内容相似的库：
- react-native-config，可以从一个.env中读取配置信息，不止是js而且包括native部分。不过很显然虽然看起来很美，但是有几个问题1.无法动态设置环境变量。2.储存在配置文件中会破坏native代码结构。因此是一个看起来很美而得不偿失的解决方案。
- 还有一个react-native-env，这是一个简单的key-value传输过程。但是最大的问题是，这个api设计为完全实时从native获取的数据，因此是一个异步的api，这对js代码来说大大的降低了易用程度；同时，它也当然不会提供app的基本信息，还是需要使用者自己去实现。
综上所述，回到我们的方案，基本上是在代码入侵最小的程度上，最恰当的满足了当前的使用需求，同样也是小而美吧？

当然，这两个组件抽象出来主要是为了自己使用，接下来会继续抽出基础组件。