会津ラボ

React Nativeのアプリ開発やReactのSPA開発において認証フローは、クオリティを左右する重要な要素であることは間違いない。 実際、検索結果には、認証フローに言及した記事や質問が投稿されていて関心の高さが伺える。その内容としては、ルーター設計における認証フローに関するものが多くを占めている印象だ。 そしてReact Nativeのルーター設計には、React Navigationやreact-native-router-fluxが使われるが、いずれもルーター・ナビゲーションライブラリであって認証ロジックを提供していない。すなわちルーターで良しなに対応するか、自作の認証ロジックをこしらえる必要がある。 このエントリーでは、React Nativeの認証フロー について考えてみたい。 そもそも… そもそもReact Navigationの公式ドキュメントに、認証フローに言及したページがある。これはナビゲーションロジックを駆使して認証コンポーネントとプライベートコンポーネントを振り分けるというものだ。 まったくもって理にかなう認証フローだと思う。 その内容で十分だと思うならば、そちらを参考にするのがよいだろう。ただし認証ロジックを提供するものではないことは理解しなければならない。 認証フローのデモンストレーション AppScreen.js AppNavigator定数がメインナビゲーションに該当する。認証後に表示されるコンポーネントだ。AppNavigatorをcreateAppContainer(…)にセットした上で、withAuthenticator(…)にセットする。withAuthenticatorは、高階コンポーネントになっていて条件によって別コンポーネントを返す。 withAuthenticator.js まずconstructor(props) {…}で認証トークンを取得済みか否かを確認する。その結果で認証コンポーネントかプライベートコンポーネントに振り分ける。 認証トークン取得済みであればprops.authenticate(true);を実行して、this.props.isAuthenticatedの状態を更新する。これによってif (isAuthenticated) return <Component />;のコンポーネントが返される。すなわちこれは、AppScreen.jsで定義したcreateAppContainer(AppNavigator)を参照する。 認証トークン未取得であればprops.signIn();を実行して、this.props.authStageの状態を更新する。これによってswitch (authStage) {…}のcase types.SIGN_IN:が該当する。したがってサインインコンポーネントが返される。 authentication.js Reduxのaction-creatorとaction-type、reducerをまとめている。いわゆるDucksというデザインパターンだ。 stateにはisAuthenticatedとauthStageを定義している。この状態を更新するためにaction-creatorのforgotPassword、signUp、signIn、authenticateがある。 forgotPassword、signUp、signInは、authStageの状態を担当し、action-typeの定数値に更新する。 authenticateは、isAuthenticatedの状態を担当し、真偽値を受け取って更新する。 まとめ React Nativeの認証フロー に関する内容だった。 この内容ではReact Navigationを使っているが、react-native-router-fluxであっても再現可能だ。AppScreen.jsのwithAuthenticator(…)にreact-native-router-fluxのルーターコンポーネントをセットすればよい。 ただこの認証フローにも悩みどころがある。 React Navigationかreact-native-router-fluxに関わらず、認証コンポーネントはナビゲーション管轄外になっていることで、ヘッダーが表示されない。認証画面などにもヘッダーが必要ならば、NativeBaseなどのUIコンポーネントでヘッダーUIを挿入したり、各コンポーネントもナビゲーション化しなければならない。 UIコンポーネントを使う手段は、ヘッダーUIに差異が発生するから却下だろう。ナビゲーション化は、せっかく振り分けたのに、どこかモヤモヤする。 素直にReact Navigationの認証フローに倣ったほうがよいのかもしれない。 このエントリーが、あなたのクリエイティビティを刺激するものであると期待したい。

React Navigationのルーティング設定で、ヘッダーUIとタブバーUIを含むとき、タブ切り替えナビゲーションを担うcreateBottomTabNavigatorを使う。 ところが、createBottomTabNavigatorではヘッダーUIが表示されない。 タブバーUIにおいて、ヘッダーUIが不要なケースがあるかもしれないからヘッダーコンポーネントを含めていないと思われる。しかしその一方でcreateStackNavigatorだとヘッダーUIが表示される。 感の鋭いひとは、気づいたかもしれない。createBottomTabNavigatorとcreateStackNavigatorを複合的に使うことでヘッダーUIとタブバーUIの配置を実現できるということに。 このエントリーでは、ヘッダーとタブバーの要件を満たすReact Navigationのカスタマイズ方法を紹介したい。 createBottomTabNavigatorでタブバーUIを表示する 以下ソースコードを見てほしい。 createBottomTabNavigator APIを使っている。createBottomTabNavigatorの引数には、オブジェクト形式でHome, Cart, Settingプロパティが確認できる。各プロパティには、さらにオブジェクト形式でscreen, navigationOptionsプロパティがあり、screenに任意のReact.Componentを適用して、navigationOptionsでタブラベルを設定している。 タブバーUI設置は実現しているが、例によってヘッダーUIは表示されない。 createStackNavigatorでヘッダーUIを表示する 以下ソースコードを見てほしい。 行数が増えているが、実は、いたってシンプルだ。前述のソースコードからの変更点は、screenプロパティにcreateStackNavigatorを書いている。以下、差分キャプチャを見てほしい。 createBottomTabNavigatorのscreenにcreateStackNavigatorを展開しているだけだ。オブジェクトがネストして分かりにくさを覚えるが、createBottomTabNavigatorとcreateStackNavigatorのコンポーネントを通して任意のコンポーネントが表示される仕組みになっている。 果たして、タブバーUIとヘッダーUIを表示することができた。 まとめ ヘッダーUIとタブバーUIの要件を満たすReact Navigationのカスタマイズ方法の紹介だった。 「createBottomTabNavigatorのscreenにcreateStackNavigatorを展開している」と表現して、わたし自身があらためてスッキリした。ネストが多くてややこしいのだけれど、createBottomTabNavigatorのつもりで記述を済ませてからcreateStackNavigatorを書き加えると迷子になりにくいかもしれない。 このエントリーが、あなたのクリエイティビティを刺激するものであると期待したい。

アプリケーションのテキストフィールドのキーボードが、入力タイプによって最適化されることを思い出せるだろうか。メールアドレスフィールドだったり、電話番号フィールドだったりがわかりやすいかもしれない。メールアドレスを入力する場合は、＠やドットが配置されていて、電話番号を入力する場合は、数字や#＊+等の記号が配置されている。 このようにユーザーが入力しやすい機構が用意されているわけだが、テキストフィールドの入力タイプはエンジニアが明示しておく必要がある。 HTMLならば、<input>のtype属性にtextやpassword、numberなどを指定して、React Nativeならば、<TextInput>のkeyboardType propsにdefaultやnumber-padなどを指定するとキーボードが最適化される。 このエントリーでは、keyboardType propsの指定におけるキーボードビジュアルの違いを確認したい。 キーボードタイプの対応表 default number-pad decimal-pad numeric email-address phone-pad ascii-capable numbers-and-punctuation url name-phone-pad twitter web-search visible-password default number-pad decimal-pad numeric email-address phone-pad ascii-capable numbers-and-punctuation url name-phone-pad twitter web-search visible-password まとめ keyboardType propsの指定におけるキーボードビジュアルの違いについて確認してきた。プラットフォーム間においても、未対応のものがあって案件によって使い分けを検討するケースもあるかもしれない。とはいえ、適切なキーボードタイプの設定は、ユーザビリティ向上が見込めるため積極的に適用すると良さそうだ。

react-native-router-fluxを使ってRouter設計するとき、タブバーUI用にTabsコンポーネントがある。アプリのスクリーン下部にあるナビゲーションUIのことだ。 タブバーデザインにおいてよほどの理由がない限りは、Tabsコンポーネントを使う。UIコンポーネントを利用すれば同様のものが設置できるし、自作タブバーにすることもできるが、わざわざそうする理由もない。なにより遷移設定が面倒くさい。 そんなTabsコンポーネントであるが、アクティブ時のカラーや非アクティブ時のカラーをカスタマイズするpropsがある。これを書き加えることで、タップしたときに色を変えられるわけだ。 しかしアイコン表示において手こずった事案があった。 このエントリーでは、フォーカスされているタブのアイコンにアクティブカラーをつける方法を共有したい。 react-native ^0.59.8 react-native-router-flux ^4.0.6 native-base ^2.13.4 タブバーにアイコンを表示する まずはRouter設定をする。使うコンポーネントは、 <Router> <Tabs> <Scene> の3つ。タブは「ホーム、カート、設定」を切り替える単純なものを想定している。 上記ソースコードのコメントアウト行を見てほしい。 各タブにアイコン設置するため、<Icon>を使っている。これはNativeBaseのIconコンポーネントだ。<Scene>にそれぞれ設定することでアイコンが表示される。以下のようになると思う。 つづいては、タブがフォーカスされたときにアクティブカラーを着色する工程だ。 タブがフォーカスされているとき（されていないとき）のカラーを指定する タブをタップしてフォーカスされたときに、テキストおよびアイコンがアクティブであるとわかるようにカラーを変えたい。 上記ソースコードのコメントアウト行を見てほしい。 activeTintColor propsがアクティブ時のカラーコードで、inactiveTintColor propsが非アクティブ時のカラーコードを設定している。いずれのpropsも文字列を受け付ける。 現在フォーカスされているホームタブのテキストはアクティブカラーになっている。ところが、アイコンのカラーは変わっていない。それもそのはずで、外部のコンポーネントなのだから仕方がない。 <Icon>は、NativeBaseのコンポーネントだった。アイコンのカラーを変更するには、style propsにオブジェクト形式で、CSSを記述すればよい。 上記ソースコードのコメントアウト行を見てほしい。 <Scene>のicon propsに設定した関数の引数から、focusedを受け取っている。これは真偽値が格納されている。つまりタブがフォーカスならtrueというわけだ。 style propsに、focusedがtrueならアクティブカラーで、falseなら非アクティブカラーがを渡している。これにてアイコンにもアクティブカラーを付与することができた。 まとめ フォーカスされているタブのアイコンにアクティブカラーをつける方法の共有だった。 この内容では、NativeBaseのIconコンポーネントを使っているが、自作のsvgアイコンやほかのUIコンポーネントであっても同様のことができるはずだ。focusedを受け取ってフォーカスか否かを確認して切り替えればよいのだから。 このエントリーが、あなたのクリエイティビティを刺激するものであると期待したい。