【第3回】ReactNativeにゆかりのあるスタートアップが集う会 参加レポート
はじめに
React Nativeの勉強会にブログ枠で参加した。 r-n.connpass.com
シャンパン枠なる謎の参加枠があり、LT開始時にシャンパンが開けられて終始テンションの高い感じだった。 一瞬戸惑ったけど、振り返ってみると懇親会の時の人にいつもの勉強会よりかなり人に話しかけやすい雰囲気ができていたし、そういう盛り上げ方大事だな〜と思った。
Twitterのハッシュタグもけっこう盛り上がっていた。 https://twitter.com/hashtag/rnstartup?vertical=default&src=hash
自分はReact Native始めたばかりで、わからないことが多くて悔しかったので、どんどん吸収していきたい。
以下にLTとパネルディスカッションの内容をまとめてみた。
tl;dr
- みんなの関心は ネイティブ or Expo と テスト
- 次点でNative Module, ツール周り, 開発工数/速度
- Expo使ってる/使ってないはちょうど半々くらいだった(Expo意外に多い)
- テスト書いてるのは少数派だった😢
- RNあるある: 必要な情報が探しにくい
- 公式とライブラリのドキュメントで情報が分散してるケース
- そもそもライブラリのドキュメントが見づらかったり書いてなかったり
- よってかなりハマるケースもある、生の知見がだいじ👀
- 案件の見極め大事
- RNコミュニティの層の厚さ
- ゴリゴリに新しい技術を追っているところ
- 少ないリソースで開発してるところ
React製WebサービスをReactNativeでアプリ化した話
発表者
@t0m0210s さん
工数
- 約4ヶ月でリリース
- 11月〜2月で開発
- 1月にNativeModuleとデザインのブラッシュアップ
- 2月末〜 課金、Apple審査
- 3月テスト
開発
- 1, 2週間に一回、リリースビルドしたアプリを触る会をやった
- 機能追加や改善含めブレストする
- WebViewをどんどん使う
- グラフや課金モーダルはWebViewで実装した
- 変更の多いところ、複雑なところはWebViewを使う
- 開発は iOS のみに注力
リリース時にやっておいてよかったこと
- Sentryによるエラー検知(一番やっておいてよかったこと)
- Bitriseによる自動リリース
- AppsFlyer, FirebaseAnalyticsなどのアナリティクス周り
- AppFollowなどのAppStoreレビューやアナリティクス通知
RNの良い点・辛い点
良い点
- WebのReact資産があれば、爆速で開発ができる
- Reduxなどは、ほぼそのままWebのものを持ってこれた
- インターン生などの開発経験が浅い人との役割分担ができた
- 途中で大幅なデザインブラッシュアップがありつつも、爆走で開発できた
- もし資産がなくても、フロントエンドエンジニアがいればけっこういける
- いいパッケージがあればコピペでNativeが動く
- WebのReact資産があれば、爆速で開発ができる
つらかった点
react-native-firebaseのあるある早く言いたい
www.slideshare.net
発表者
@tkow39 さん
- ReactNativeにゆかりのあるスタートアップが集う会 LT皆勤賞
- Leverages 新規事業開発所属、元teratail開発メンバー
- terascout をiOS版のみリリース(β版)
react-native-firebase
- Firebaseを使うなら、firebase-web-sdkよりもreact-native-firebaseのほうが高機能
- Expo の eject推奨
- 自分が使いたい機能だけ使うことができる
Authentication
以下のような機能が一瞬で実装できる
あるある: 同じメールアドレスで違うSNSアカウントを登録できないことにハマる
- できなくはないがバグが多い
- Firebaseの設定でdisableにするのを推奨
DeepLink認証
- リンクを開いたデバイスの種類によって挙動を変えられる
直接アプリに遷移もできる
あるある: ドキュメントがいろんなところに分散している故に初期設定が超めんどくさい
- RN公式
- Firebase公式
- react-native-firebase
handleCodeInAppをtrueにするとappに直接飛べるになる
(FireStoreについては発表時間切れになってしまったので、スライドを参照。)
React Native アプリをどうテストしてますか
発表者
@L_e_k_o さん
- CureAppのチーフエンジニア
- Javascript(Node, TypeScript, React Native)
前提
- E2Eテストじゃないとテストできないことを、単体テストに切り出していく
- Universal Javascript(ふつうのJS)はテストできるので、それ以外の箇所
ミドルウェアのモック
importした外部ライブラリを直接使うとモックしづらい- 高階関数から渡してあげるようにするとモックしやすい(
interface injection) - jest.mockでも可
テスト断面
- 複数の条件が必要なテストはめんどくさい
- テストはめんどくさいとどんどん書かれなくなっていく悪循環
- 事前条件をゆるくしてあげる(= テスト断面を増やしてあげる)
Node.jsのテスト
- supertestというライブラリが便利
- Cookieの引き継ぎとかもできる
- supertestは実質E2E
- HTTP層とロジックを分離してあげれば普通にかける
コンポーネントのテスト
- storybook/storyshots
- Storybook使っていれば && コンポーネント自体が複雑なロジックを持っていなければ使える
- storiesを定義しておくだけでスナップショットテストができる
- 少なくともエラーが起きないかどうかをテストできる
- propsのパターンを網羅するのだけがめんどくさい
ネイティブモジュールのテスト
- 一部のネイティブモジュールはSimulatorではテストできない
- ex: Bluetooth, Push通知
- 現状は実機でまごころこめて動作確認しかない...？
RN の Upgrade に近道なんてねぇんだよ
発表者
@natural_clar さん
RNをアップグレードしたい理由
- 0.56: Babel 6 から Babel 7 に移行した
- 0.57: TypeScript の導入が容易に
- 0.59: React Hooks が使用可能になる
RNをアップグレードせざるを得ない理由
- 0.55.4: 日本語、中国語の変換が確定されてしまうバグ
- 0.57.2: (monorepo の場合)他の Package にある Assets から画像が読み込めないバグ発生
- 0.57.5: XCode 10の新ビルドシステム対応
アップグレードでやらなきゃいけないこと
- Dependency対応
- build.gradle, .pbxproj ファイルの変更
- Native知識がないとツラい
- Babelのライブラリ(0.56での鬼門)
- rn-cli.configの変更(0.57での鬼門)
- バージョンアップは0.56と0.57が鬼門で、それ以降は辛くない
バージョンアップツール
- RNのバージョンアップツールはワークしなかった
- (旧)react-native upgrade
- react-native-git-upgrade
- 動かなくなって、Killされてしまった
rn-diff-purgeで差分を見て粛々とDiffを見ていくのが一番の近道- 0.59 以降ならこれを用いた新react-native upgradeが使用できる
React Native×GraphQLで開発したら便利だったお話
発表者
@mediaboxe さん
- ORSO テクニカルリレーションマネージャー
- 最近はReactNative, LineClova, IoTをやっている
GraphQLとは
- Web APIの規格のひとつ
- queryリクエストとmutationリクエストの2つでできている
- RESTでいうとqueryはGET、mutationはPOST, PUT, DELETEにあたる
- queryはクライアント側で欲しいパラメータを指定できる
- mutationは戻り値で欲しいパラメータを指定できる
- React NativeだとApollo Clientというモジュールがデファクトスタンダード
Apollo Client
- キャッシュの自動更新が便利
- キャッシュの更新が簡単
- API数が減らせる！
- 取得パラメータを改修しやすい
- デメリットもある
- キャッシュの追加と削除は大変
- 通信のエラー制御が大変
- アラートだらけになってしまう
E2EテストライブラリDetoxの導入でハマった話
発表者
@ariiyu さん
- ウォズ株式会社 代表兼エンジニア
- RN歴1年半、iOS歴4年以上
- キッチハイクの開発を手伝ってくれてる
Detox
Detoxの仕組み
- テスト層とアプリ層をDetox serverが仲介する
- テストは非同期
- Detoxは自動的にテストとアプリを同期する
- sleepを書かなくてすむのでテストが安定する
テストがコケる
- テストがハングしてタイムアウト
- 非同期オペレーションを待機し続けてしまう
- 要素が見つけられない
- 待機が十分でない
発生したバグ
- 無限ループのアニメーションでハングアウト
- デフォルトでアニメーションが終わるのを待機する
- 対象の要素が出現前にテストが失敗する
- Push 通知許可のアラートを押せない
- あらかじめ設定しておく
- Androidで要素が検出されない
地道なデバッグ
- エラーログをみる
- 待機が長い処理を調べる
detox test --debug-synchronization 10000
- Xcodeの
Debug View Hierarchyでビューの階層をみる - コンポーネントごとにコメントアウトしていく
Detoxどう？
- テスト自動化できそう！
- ドキュメント、issueはまとまっている
- 自動同期はいつもうまくいくとは限らない
- 現状はワークアラウンド必須？
- テストのときだけファイルの差し替えなど
- そもそもアプリの実装、テストコードの見直しも必要
WebエンジニアのReactNativeでの戦い方
www.slideshare.net
発表者
@NaoshiHoshi さん
現状
- iOSのアプリの開発継続が困難だった
- 実装者は退職済み、仕様を知っている人が非エンジニアしかいない
- エンジニアは自分と学生バイトのみ
- ネイティブアプリの開発知識はなし
- ネイティブアプリエンジニアの採用も困難
RNに踏み切った背景
- PMFを目指して高速で開発したい
- 限られたリソースのなかで効率よく開発したい
- PWAと悩んだが結局RNにした
- メインのユーザー層が若いのでアプリの方が使われそう
- PWAだとデザイナーの採用難易度が高くなる
Webエンジニアの戦い方
- JavaScriptの世界で戦う
- expo detachは絶対しない
- ビジネスサイドとの期待値調整をやる
- ReactNative + Expoでできないことはやらない
パネルディスカッション(抜粋)
パネラー
@t0m0120, @natural_clar, @mediaboxes, @ariiyu
Push通知/ネイティブ機能が不要なアプリを作りたいとき、PWAとRNどっちでつくる？
- 機能要件だけじゃなく、ユーザ層も含めて検討する
- RNにするなら
- ストアからの流入を見込みたい場合
- いずれPush通知/ネイティブ機能が必要になりそうな感じがする場合
- 対象のユーザ層が若い場合
- PWAにするなら
- 更新が早い場合
- 複雑さや自由度を求められる場合
業務委託のエンジニアって採用している？
採用している。 主にUI系のタスクや、Storybookのコンポーネントを作ってもらうなどの疎なタスクを渡している
Pushのテスト気になる、社内の端末かきあつめている
Push通知のテストはまだ知見がなく、どこも自動化はできていない。
ejectの是非とタイミングについて
- 要件に依存する部分が大きい
- Bluetooth を使う機能などは、Expoでは実現できない
(Expoを使っている人に)Expoを使っているなかで、Expoが理由で泣く泣く諦めた機能とかある？
- 要件を全く満たせないことは少ないが、細かい仕様が満たせなくて歯がゆい時は多い
- 例1: スワイプ機能の細かい処理(
react-native-swiper) - 例2: Facebookなどのシェア機能
- 例1: スワイプ機能の細かい処理(
