【第4回】ReactNativeにゆかりのあるスタートアップが集う会 参加レポート
はじめに
ふたたびReact Nativeの勉強会にブログ枠で参加した。
https://r-n.connpass.com/event/126775/
前回に引き続きシャンパン枠のひとが開幕と同時にシャンパンを開けてひと盛り上がりするし、今回はFlutter枠というRNのライバル(？)フレームワークの発表がいくつかあったり、技術書販売枠の人が先日の技術書展で出した本を売っていたりした。
謎の刺客がシャンパンを持って現れた！#RNstartup pic.twitter.com/kG0Hx63Rre
— かん / ワンディー株式会社COO (@kangyoosam) April 25, 2019
この勉強会はそんな独特な枠があったり、テーマやRN歴/プログラミング歴の縛りなどがないので、良い意味のカオスというか、Melting Pot感がある。
個人的には毎回新しい話題に触れられるし、知らないことに「？」となることも多いが、知るためのモチベーションにも繋がりやすいので、よいと思ってる。 来月(5月)はおやすみで、6月に渋谷にて100人規模で開催するらしい。楽しみ！
tl;dr
- 今回は
FlutterとTypeScript回だった- Flutterの強み: 描画ロジックがOSに依存しない、ホットリロードの速さ
- Googleの開発する言語だし、将来性はかなりありそうな感じ
- Flutterの強み: 描画ロジックがOSに依存しない、ホットリロードの速さ
- TypeScriptのAny容認派/Any断固反対派の溝は深い
- 容認派の意見
- ひとまず入れることだけでも意味は大きい
- Anyを入れることでゆるやかに導入できる
- 断固反対派の意見
- 型の安全は完全にしないと意味がない
- Any入れるくらいならTSにしないほうがマシ
- TS使ったことない/ゆるい型の言語しか馴染みのない自分としてはまだピンときてない
- チーム開発/スピードが求められるところだと、あんまりカッチリしすぎてもうまくいかないような気はする...
- 容認派の意見
広告計測してと言われた時にReact Nativeエンジニアが詠む資料
発表者
@syokenz さん 株式会社キッチハイクのCTO。
キッチハイクの広告計測の概要
- AppsFlyer, Google Analytics for Firebaseの二刀流
- 広告タップ〜アプリインストール(アプリ外部/ユーザ獲得)の計測: AppsFlyer
- アプリ起動後〜課金(アプリ内部/ユーザ行動)の計測: Firebase
なぜ分けているのか
- AppsFlyerとFirebaseでは得意分野が違う(失敗談でも触れる)
- AppsFlyerでもアプリ内分析はできないことはないけどFirebaseの方が得意
- Firebaseでもアプリ外分析はできないことはないけど(略)
使用ライブラリ
- react-native-appsflyer
- AppsFlyer公式
- READMEが充実しているし、サポートもすぐ答えてくれる
- react-native-firebase
- サードパーティだが、公式サイトでも紹介されている
- 多機能
使い方
- イベント内部でtrackEvent関数をコール
失敗談
- ストアで見るより新規インストールが多い
- AppsFlyer SDKを入れたアプリへのバージョンアップでも計測されてしまう(AppsFlyerの営業さん談)
- AppsFlyer側のDBにIDがないと新規ユーザとしてカウントされてしまうため
- Debugビルドでも計測されてしまう
- 開発環境ではif文で止めましょう
- Firebaseで全部やろうとした
- Firebase Dynamic LinkがAppStoreの計測でうまくいかなかった
- AppsFlyerの導入で解決
- AppsFlyerで全部やろうとした
- Firebaseのアプリ内分析が使いやすい
- Audiencesによるフィルタ
- アプリバージョンや年齢などのプロパティがデフォルトでセットされている
- Audiencesでフィルタしたユーザにプッシュ通知を標準機能だけで実現可能
- AppsFlyerでは有料
- Firebaseのアプリ内分析が使いやすい
Vue.js - ReactNative - イマ Flutter
発表者
@oligin020 さん
株式会社ファームノートのインタラクションデザイナー/フロントエンドエンジニア。
デザインツールSTUDIOの技術顧問も担当。
MLP(Minimum Loveable Product)の概念
- MLP(Minimum Loveable Product)
- 愛される最小のプロダクトを作る
- MVPでは作り込みは悪とされる風潮がある
- 演出の作り込みができない
どうやっているのか
- プロダクト設計のサイクルとデザイン設計のサイクルを分離して、2つのイテレーションを回す
- Bootstrapのようにデザインフレームを作り込んで、プロダクトに混ぜ込む
RNでインタラクション実装はたいへん
- アニメーションの表現を追求すると、RNだと物足りなくなる
Flutterへの移行
- 描画結果がOSで変わらない
- 触り心地の良いUIを実装できる
- プラットフォーム固有のバグも少ない
- Google 謹製
- RNを書いていたら、1ヶ月くらいで書けるようになる
- Webのほうは腹をくくって書き直す
- アーキテクチャ、設計思想が近いので読み替えでいける(状態管理など)
VueNativeとReactNativeでキメラアプリを作っている話
発表者
@iwsksky さん 株式会社ジラフのエンジニア。 質問箱をRNで書いている。Android開発歴が長い。
VueNativeをRNと共存させつつリプレイスしていっている
- VueNativeとは: Vue.jsでアプリをクラスプラットフォーム開発できるRNのラッパー
- なぜリプレイスするのか(VueNativeのつらみ)
- RN以上にドキュメントが存在しない
- ライブラリがただラップしているだけのものが多い
- 依存モジュールのバージョンが古い
- 完全に開発止めるのはむりなので、緩やかなリプレイスしていってる
いちおう共存はできてる
transformerをかませることで、一緒にビルドできる- propsの定義さえ一致していれば、tsxからVueを呼べるので、既存のコンポーネントをよびだせる
- アーキテクチャは共通してる
- vuex, reduxの共存も、(冗長になるが)できる
PanResponderを振り返る
www.slideshare.net
発表者
@14__oz さん 株式会社オープンエイトのAndroid(Kotlin)/RNエンジニア。
PanRespnderとは
フリック入力をつくる
- x軸, y軸にどのくらい動いたかを判定する機能を使う
- タップ判定を定義する
- x軸/y軸方向への動きの量が基準値より小さかったらタップと認識する
- フリック判定を定義する
- x軸/y軸方向への動きの量が基準値より大きかったらフリックと認識する
- フリックの方向は移動量の差分の正負で判定できる
JavaScript製npmパッケージをTypeScriptで書き直した話
発表者
@hmktsu さん 株式会社g&hのエンジニア。 実践Expo の著者で、先日の技術書展で#1人チーム本を出版している。
自前のJSライブラリをRNでリライト
- react-native-simple-twitter
- react-native-store-version
- ストアに公開されているバージョンとインストールされているバージョンを比較してくれる
やる作業
- jsx記述があるjsを.tsxに変更
- jsx記述があるjsを.tsに変更
- d.ts(型定義ファイル)に型を記述する
- パッケージにどんな型の関数があるかを教えてくれる
- 型がわからないとき、悩んだときはanyつかえばいい(any容認派)
所感
- eslintがTSに対応したのでとても楽
- npmで公開する場合と、通常のアプリ制作ではConfigファイル(tsconfig.json)に設定する内容が違う気がする
- d.tsを自動でひとつにまとめることはできない
- 現状では、中規模以上のライブラリだと複数d.tsがあることを容認する必要がありそう
Flutterはなぜ楽しいのか
発表者
@eyasuyuki さん フリーランスのAndroid/iOSエンジニア。
Flutterのいいところ
- 環境構築が楽
- デフォルトで入ってるLintが便利
- Firebaseとの連携も楽
- Dartの言語仕様がシンプル
- Javaにけっこう似てる
- ホットリロードはやい
- UI構築が楽
- すべてが
Widgetという概念
- すべてが
- Android StudioにFlutterのプラグインを入れるだけで書き始められる
- ゆくゆくはmacOS, Windowsアプリ, Webアプリの開発もできるようになる構想がある
Debugging React-Native
発表者
@natural_clar さん
デバッグツールの使い分け
- 以前はreact-native-debuggerを使っていたが、やめた
- 動きが重くなった
- Hooksとの互換性がない
- 以下の2つを用途によって使い分けている
- debugger-ui(デフォルトのデバッグツール)
- なんだかんだで機能が揃っている
- react-devtools (おすすめ)
- state変更の速度を計測できる
- inspectorでスタイルの調整とかもできる
- debugger-ui(デフォルトのデバッグツール)
