家計簿アプリ制作の理由
西仲幸太氏：僕からは『React Nativeで家計簿アプリを作って得たもの』について共有します。
まず自己紹介を。西仲幸太と言います。担当プロダクトはメール配信管理プラットフォームというバリバリのバックエンドです。好きな言語はJavaScriptで、今回の話にも出てくるReact.jsやNode.jsをTypeScriptで書くのにハマっています。
今日の流れですが、はじめにデモを含めたアプリの紹介から。そのあと技術を紹介しようと思っています。実はちょっと前にインターナルで紹介したこともあって。そのときはReact Navigationを説明しました。なので、今回はReduxとFirebaseを中心に説明しようと思っています。
僕の話を聞いて、こういう技術を使ったらこんな感じのものが作れるんだなぁっていう感覚をもってもらえればうれしいです。
作成中の家計簿アプリを紹介します。なんで、今さら家計簿アプリなんだと思う方もいるかもしれません。理由としては、家族で家計費をつける際に、僕が複雑な計算をいつもしていました。方法も既存の計算では難しくて、Excelとかでやっていたんです。月末に入力しているんですが、それが面倒くさくて。家族みんながアプリで入力できるようにしてほしいということだったので、作り始めました。
簡単にデモを実践します。今実際に動かしているアプリよりも古い画面ですが、今回説明する内容が入っているので、これで説明します。まず、メールアドレスとパスワードを入れて認証。これはFirebaseの基本的な標準機能である認証部分になります。
実際にアクセスして、個人がどのくらいお金を使ったのかを計算できるようになっています。個人ごとの一覧が出るので、その月の何に使ったのかが見れます。
先ほどちょっと複雑な計算と説明したのが、日付や使った店舗を入れるところです。負担額というところを入力して、例えば1200円の負担額は個人用200円で、家計簿から徴収済みとチェックを付けています。
これはお店で1200円分の買い物をしました。自分だけに利用するものとして200円、家族の家計費から自分用のもので200円を使うことになります。なので家計費としては1000円使いました。ただ家族で共通の口座をもっていて、そこからお金は回収している証として、家計費から徴収済みというチェックを付けています。
これを付けることで、月末の計算時に徴収する必要がないお金であることをチェックできるようにしています。こんな家計簿を作りたいと思いました。
アプリで使っている技術
次は技術の紹介です。アプリはかなりシンプルな構成です。ユーザーからReact Nativeを使ったアプリを通して、データはFirebaseにストアしています。
使っている技術は、ReactやReact Nativeのデバッガー。TypeScriptとExpo、今回ちょっとだけ触れるReact Navigation、ReduxとFirebaseもあります。
今回はFirebaseとReduxを中心に説明します。
Reduxについて
はじめにReduxから。Reactに触れた方はだいたいReduxそのものにも触れているかなと思います。ReduxもHooksを2019年6月ぐらいにリリースしているので、そこの書き方をちょっとだけ今日は紹介しようかなと思っています。
これが先ほどの一覧画面で、毎月1ヶ月に対してどのくらいの金額を払っているかのリストを出しているロジックです。赤線引いているところだけを見てください。赤線の箇所はReduxのHooksのロジックになっています。
useDispatchでもってきてstateし、今のユーザーが誰なのかをuseSelectorで引っ張ってくる。最後にsetCurrentPaymentsで支払いの情報をReduxのstateに保存するというのをやっています。
今これは3行で書けているんですが、Hooksを使う前はどうだったのかっていうと、こちらになります。ちょっとHooksのところはコメントアウトしていますが。
この2行の表現をするために、右側ではmapStateToPropsとmapDisoatchToPropsの2つをReduxのデータストアにコネクトするのを全部書いています。そこから引っ張ってきた情報をコンポーネントの引数に渡して、初めて使える感じでした。
なのでHooksを使えば、この右側のリストが丸々不要になる状態と、この2つの引数がなくていけます。なので、記述量がかなり減ることがメリットだと思います。
可読性が上がるReact Navigation
次はReact Navigationについてです。これはかなり割愛しますが、React Navigationのバージョン5が、実は2ヶ月前にリリースされました。これでけっこう書き方が変わっていて。内容自体は、興味があれば調べてもらえればと思います。
自分がちょっと使ってみたところ、書き方がタグで囲むような形式になっているので、可読性がかなり上がっていると感じました。便利だと思うので、興味のある方は調べてみてください。
FirestoreとRDBMSの違い
次にメインのFirebaseについてです。今回のアプリはFirestoreを使っています。まだFirestoreを触ったことがない方もいると思うので、まずは簡単な説明を。
FirestoreとRDBMS、リレーショナルデータベース、普通のOracleとの違いを見ていきます。Firestoreはドキュメント指向のNoSQLと言われているものです。エンドユーザー（クライアント）から直接Firebaseにアクセスできます。
基本的なOracleとかのデータベースを使った場合。実装する際は、Reactとかで作ったクライアントサイドから、NodeやJavaで作ってサーバーサイドにアクセスする。そこからサーバーサイド側でデータベースとやりとりします。いい感じに加工したのをクライアントに返して画面に描画する、というのが基本的な流れかと思うんですが。
そこのサーバーサイドのところを飛ばして、Firestoreに直接アクセスして記述できます。バックエンドで考えると、バックエンド側だとユーザーの認証をどうするか、データのバリデーションはどんな感じにするかを考える必要があると思います。メリットとしては、はじめの段階で節約できることではないでしょうか。
Firestoreの特徴は、先ほど説明したとおりクライアントから直接Firestoreにアクセスできることです。これまでサーバーサイドで受け取った場合は、サーバーサイド側で加工していい感じにクライアントに返して表示する、これが基本的な書き方だったと思うんですが。
DBから直接データをクライアント側に取るので、取った時点でできるだけいい感じの形式になっているのが望ましいです。なのでFirestoreを実装するときのポイントは、RDBとデータのモデリングの形式がぜんぜん違うところを、取ってきた時点でいい感じに表示できるようにするかが、今後の課題ではないでしょうか。
Firestoreに備わった3つの機能
Firestoreの3つの機能を紹介します。Firestoreのいいところとしてまず1個目に定義できるのが、セキュリティルールです。普段はサーバーサイドでバリデーションとかをゴチャゴチャやると思いますが、Firestore側でセキュリティのルールを設定できて、そこでバリデーションがこういうふうに働くという設定を組めるのが特徴の1つです。
2つ目がリアルタイムリスナーで、Reactとかなり親和性が高いシステムだなぁと思っています。機能としては、最新の状態をアプリケーションと同期可能です。
通常なら、僕らがクライアント側で最新情報があるかをサーバーサイドにアクセスして確認すると思いますが、リアルタイムリスナーなら、Firebaseのデータベースが更新されていたら、そこからクライアントに通知して、リアルタイムにデータを同期してくれます。これがいい機能の1つだと思っています。
3つ目がオフライン対応で、名前のとおりなんですが、オフライン状態でも読み取りができ、DBがつながらない場合でもキャッシュからデータをもってこれます。書き込んだときはつながらなかったとしても、キューに蓄積することも可能です。
FirestoreはRDBと考え方が違うので、学習コストは低くないですが、めずらしい機能もあるので、ぜひ使ってみてください。
まとめとしては、React NativeもReactです。React NativeはReactのよさや仮想DOM、単一のデータフロー。他にもコンポーネント指向になっている部分やReact Nativeと、書いてあるとおりなんですが、そのままよさは全部もっています。そこが、React Nativeそのもののよさではないでしょうか。
今回使ったReact NativeとExpo、Firestoreを使うと、それなりに早くアプリの開発が進められます。みなさんもぜひ試してみてください。発表は以上です。
