TL;DR

・Native Baseに安易に手を出すとはまりがち
・正直おすすめしない

モチベーション

受託や業務委託でReact Nativeの開発をしているのですが、
過去と進行形合わせて２プロジェクトほどNativeBase導入済みの案件にJoinし
結局NativeBaseを外した(orゆるやかに外す方向で進めている)ことがあるので、どこが問題になるのかのメモ

つらみ1: リスト

https://docs.nativebase.io/Components.html#Layout

公式のドキュメントにもありますが、件数が多い時にはFlatListに置換えた方が良きです。
なぜなら、、中身がただのViewかListViewか、だったりするので、パフォーマンスの問題やバグの温床になる可能性があります
https://github.com/GeekyAnts/NativeBase/blob/master/src/basic/List.js#L187

render() {
    if (this.props.renderLeftHiddenRow || this.props.renderRightHiddenRow) {
      return (
        <ListView
          {...this.props}
          ref={ref => {
            this.setRefs(ref);
            this._root = ref;
          }}
          enableEmptySections
          onScroll={e => this.onScroll(e)}
          renderRow={(rowData, secId, rowId) =>
            this.renderRow(rowData, secId, rowId, this._rows)
          }
        />
      );
    } else if (this.state.dataSource) {
      return (
        <ListView
          {...this.props}
          ref={ref => (this._root = ref)}
          enableEmptySections
          dataSource={this.state.dataSource}
          renderRow={this.props.renderRow}
        />
      );
    }
    return (
      <View ref={c => (this._root = c)} {...this.props}>
        {this.renderChildren()}
      </View>
    );
  }

つらみ2: ScrollViewをどこでも使いがち

たとえば、レイアウトの基幹になるようなContentコンポネントがだったり。
https://github.com/GeekyAnts/NativeBase/blob/master/src/basic/Content.js#L126

Tabsの内部スクリーンがScrollViewでwrapされていたり。
https://github.com/GeekyAnts/NativeBase/blob/master/src/basic/Tabs/index.js#L167

上記のリストの問題とも絡むのですが、FlatListなどをつかったときにScrollViewのなかにFlatListといった実装になってしまい、スクロールのイベントがとられてしまったりパフォーマンスの問題になったり(FlatListがflex:1で広がってしまうので)で困りがちです。
そして、Contentのようなレイアウトのベースになるようなコンポネントがそうなので、外す時に大変だったりします。

つらみ3: カスタマイズに時間がかかる & 元のコードを追わないといけない

https://github.com/GeekyAnts/NativeBase/blob/master/src/basic/Header.js
例としてHeader.jsなのですが、
iPhoneXでレイアウトを調整したいときに、heightの上書きができない問題がありました。
中をみてみると、、iphonex向けに高さを計算し、props.styleをうわがいていたのでした、、

Header.js

        {variables.isIphoneX ? (
          <View
            ref={c => (this._root = c)}
            {...this.props}
            style={[
              this.props.style,
              {
                height: this.calculateHeight(
                  this.state.orientation,
                  variables.Inset
                ),
                paddingTop: this.calculatePadder(
                  this.state.orientation,
                  variables.Inset
                )
              }
            ]}
          />
        )

こういったカスタマイズの都度、コードをを追わないと、結局なかで何のコンポネントがどう使われているのか不明なので読み込むのに時間がかかってしまいます。
効率化のためにUIライブラリ導入したはずが、スクラッチで作るよりも時間かかってしまうということも。。

つらみ4：テーマのカスタマイズ

ejectしたり、getThemeしたりconnectStyleしたりやっていけばいいのですが、variableを追っていくのが大変なのと、typescriptでの型が面倒だったのであきらめました。ejectすると元のベースがマテリアルデザインだったり。

参考：元ドキュメント
http://docs.nativebase.io/Customize.html#custom-component-headref
b

NativeBaseの代替案

もしコンポネントだけどなにかライブラリいれたいのであればreact-native-elementやreact-native-paperとかを薄く使うのがいいのでは?と思いました。
が、もしデザイナーさんがおり、デザイン要件が込み入ってきそうなアプリであれば、独自で作っていくのも、遠回りのようで近道かもしれません。

最後に

いろいろ書きましたが、結局要件次第では問題なく使えるのかもしれません。実は知らないだけでいい使い方があるのかもしれません。
たまたま自分が関わったアプリではダメでしたが。。

あとは、ソースをみていくとなんだかんだ勉強になったので、react-native-paperや他のライブラリと中身見比べてみたりも今後したいなと思いました。

NativeBase導入の際に確認した方がいいこと