前回はてぶのお気に入りフィードを読むHBFavというアプリのReactNative版RNHBFavというアプリを作っているという話を書いたが、とりあえずAppStoreへ申請するところまで終わった。razokulover.hateblo.jp申請がどのくらいで通るかはまだわからないが、たぶん1週間はかかる気がする。時間が空きそうだし、ここらで今回ReactNativeで開発〜リリース申請する中で感じたことやこうした方が良かったみたいなものをメモしておこうと思う。垂直分割/水平分割のディレクトリ構成ディレクトリ構成はプロジェクトごとにみなそれぞれ自分なりの構成を持っているようだけど、例えばreduxを利用するアプリだと以下のような作りになると思う。stylesheetや画像とか|__configureStore.js|__App.jsこれはいわゆる役割ごとにまとめる垂直分割という構成。MVCとかそういったパターンを使ったフレームワークでは馴染みのある構成。一方でページごとにまとめる水平分割という構成もある。|__buttonB.js|__configureStore.js|__App.jsactionやreducerなどをページ配下のディレクトリに全部突っ込む。垂直分割だと、ファイルが散りまくっていくので大規模な構成になった時に管理しずらくなる印象。水平分割だと、ファイルがページごとのディレクト配下に全てまとまってくので管理が楽。趣味の範囲かもしれないが、ある程度のページ数のアプリになることが想定されるのならば水平分割の構成も選択の余地がある。RNHBFavの場合は、reduxを利用しないで作る+そこまでページ数が増えないだろうという想定で垂直分割ではじめたが、徐々にページが沢山必要なことがわかる&Redux使わざるをえないみたいな状況になりやや煩雑な構成になりつつある。できるだけiOS/Androidで使えるコンポネントやライブラリを選ぶreact-native-OOOのようなライブラリが沢山あるができるだけiOS/Androidで利用できるものを使うべき。片方しか対応していない場合、最悪iOS/Android対応が詰むし、代替するとしても自分でネイティブコードを触ったり、コード内に分岐が沢山発生してしまう。ElementsなどコンポーネントのBootstrapのようなライブラリがあるが、これらはオリジナルのUIを作らないのであればiOS/Android対応もしているので便利。オリジナルのUIを作る必要があるなら下手に依存を増やしてしまうことになるので標準コンポーネントを利用したほうがよい。コンポネントを汎用化したい欲を抑えるヘッダーとかボタンとかある程度は汎用的に使えるコンポーネントもあるが、案外ページごとに微妙に使い方が違ってきたりして頓挫しがち。最初のうちはページごとに作ってみて、3回くらい同じコンポーネントを書き始めたら別ファイルに分けるくらいの気持ちで。ReactNativeはプロトタイプとかをサクッと作ることが求められてることも多いと思うし、綺麗さよりある程度雑にサッと作るくらいで良い気がする。reduxはページをまたいで情報を共有しないといけなくなってからはじめて導入を考えるべきReduxをいつ/どのように導入するかはwebのほうでも大変悩ましい問題ではあるが、アプリの場合はページをまたいで情報を共有しないといけなくなってからはじめて導入すべきと考えている。RNHBFavの場合であれば、メニューページでのお気に入りor自分のブックマークのクリックアクションに紐付いて取得されたブックマーク情報が、TOPページのタイムラインに即反映させるようにしたいといった時。メニューページとTOPページで情報元が共通化されていないといけない、これがページをまたいで情報を共有しないといけない状態。それ以外の場合は、stateで管理して、親から子コンポーネントにパスしていくやり方でいいと思う。色んなファイルにあれこれ書いたりしなくていいし、単純に理解しやすいので。以前作った某GIFビューアーではページごとにReducerを作って管理しようとしてしまって大失敗した。外部APIから情報を取得して完了したらaction発行くらいしかなかったのでredux-promiseを使った。redux-sagaあたりを検討しないといけない。個人的には非同期処理を連ねまくりたいときはredux-sagaを使う。このエントリが詳しい↓redux-sagaで非同期処理と戦うルーティングは込み入ったことしないならreact-native-router-fluxで十分Modal,Drawer,UINavigation的画面遷移でよいならこれで問題になったことない。RNHBFavではこんな感じ。Schemeに対応してないとかSP対応してないページ(SpeakerDeckとか)の表示レイアウトが崩れるなど問題が多発する。これはWKWebviewではなくUIWebViewを使ってるので発生する問題で、ReactNative側の問題。修正する気がなさそうなのでreact-native-wkwebview-rebornを使ったら良い。iOSしか対応してないのでAndroidでは標準のWebviewを使うしか無い。タイムライン系のUIはFlatList使うタイムラインのようなUIを作る時はListViewではなくFlatListを使ったほうが良い。FlatListだと数百アイテムの作成でもサクサク動く。keyExtractorなどプロパティをちゃんと設定しないとリストが更新されなかったりするので詳しくはちゃんとドキュメント読んで。react-native-vector-icons便利ほとんどのアイコンはここで調達できる。react-native-vector-icons一つ注意したいのは、アイコンは沢山種類があるがどのIconグループを利用するかは統一したほうが良い。自分は種類の多さからMaterialCommunityIconsを利用した。styleはインライン使わないwebと同様インラインスタイルはコードが読みづらくもなるし、やめたほうがよい。色やサイズは定数化して汎用的にしたほうがよいアプリ全体の統一感を出すためにも色は、ベース・ナビゲーション・リンク・テキスト・サブテキストくらいは定数化しておくと便利。フォントサイズも同様。無駄に依存を増やさ無いほうが良い。凝ったアニメーションエフェクトはできないと思え徐々に透過になったりふわっと表示されるようなああいうやつ。いうのをごりごりやりたい場合はネイティブでやったほうがよいそれでもって場合はこのへん読むと。BookESLint使うReactNativeに限らないがESLint入れてコードに統一感出しといたほうがあとあと楽。読んだReactNativeで公開されてるソースコードNativeBase-KitchenSinkコードみて各コンポーネントのStyleを見ながら標準のViewをスタイリングしていくと勉強になる。git-pointGitHubビューアー。アプリ自体良く出来てるし今も開発されてる。良さげなコンポーネントを調べるならjs.coachのreact-nativeのカテゴリhttps://js.coach/react-nativeiOSでリリースするための準備は少し癖があるリリース用にmain.jsbundleを作成する必要があるので忘れず。Resourecsに登録されてるか確認しないとリリース版でのみ画像が表示されないみたいな状況に陥る。困ったら#reactnativeでつぶやく最後に結構まとまりなく書きなぐってしまった。ディレクトリ構成とかコンポーネントに対する箇所はだいぶ異論あると思うけど、個人的にはこうやってますということで。ちなみにRNHBFavはソースも公開してるのでよかったら参考に。最近webアプリ(RailsのviewでVue.jsを使ってる感じの部分)をフ...2018-10-08Flutterの状態管理について調べたメモFlutterでの状態管理方法について雑に調べた時のメモです。ElectronでTwitterクライアントを作ったVue.jsとElectronでシンプルなTwitterクライアントを作った。»プロフィールid:razokulover本業はwebエンジニアでGIFMAGAZINEの共同創業者。趣味はハロプロ/声優/将棋/美術/読書など。浅く広く思ったことを書きます。仕事依頼は@razokuloverのDMでどうぞ。#openchat料理が上手い人RSSRSS講読のfeedbanner月別アーカイブ検索はてなブログをはじめよう!razokuloverさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。