lelelemon’s blog

カメの歩みでのんびり学んでいます。

選ぶこと、手放すこと

はじめに

こんにちは。今回はポエム寄りの内容です。技術的な話は出てきません。
最近ふと考えた、「選択する」ということについて書いてみたいと思います。
何かを選ぶということは、同時に、その選択をする前に広がっていた無数の可能性を手放すことでもある。そんなことを、少し考えてみました。

選ぶことは、可能性を狭めることでもある

進学、就職、引っ越し、旅行先、休みの過ごし方——私たちは人生のあらゆる場面で、大小問わず日々選択をしています。
就職を例に取ってみると、何の職に就くか、どの会社に就職するか、フリーランスとして独立するのか、起業するのか、複業を生業にするのか。あるいは、就職をしないという選択肢もある。
まだまだ選択肢はありそうですが、こうして無数にある中から一つ、あるいは数個を選び、そこに人生の時間を投下していきます。
もちろん、その場その場で自分が最適だと思う選択をしていくわけですが、その瞬間に、別の選択をしていたら歩んでいたであろう未来を手放しています。

もっと小さな例だと、休日の過ごし方もそうですね。時間の使い方は自由で、ずっと寝ていてもいいし、何かに熱中してもいい。
でも「今日はこれをする」と決めた瞬間に時間の使い方は確定し、他にできていたであろうことに取り組むチャンスもまた、そこで手放しています。

普段の「選ぶ」という行為の裏には、選ばなかった無数の選択肢がある。当たり前のことですが、これを意識するかしないかで、選択という行為の重みは変わってくるように思います。

すべては選べない

欲を言えば、やりたいことを同時に全部やりたい。もちろん、時間は有限で、体は一つしかない以上、現実には不可能です。
Aを数年やってみて「合わないな」とわかったとき、その数年でBをやっていたらどうなっていただろう、と妄想することがあります。
まずはしっかり計画を立てるべきだ、まずはやってみて微調整していくべきだ——いろいろな論調がありますが、いずれにしても、同時にやれることは基本的に一つなんですよね。
だからこそ、いまこの瞬間の選択は、その先の未来を形作る大きな決断になります。

正解を選ぶより、自分の信念に合う選択をする

世の中は、ビジネス書をはじめ多くの情報に溢れています。少し調べれば、どうキャリアを選ぶべきか、それなりに信頼できそうな情報に辿り着けますし、周りの人に意見を聞いてみるのもいいと思います。
でも当然、それらは一般論や、その人にとってうまくいったケースの話です。自分も同じようにうまくいく保証はどこにもありません。
同じやり方をしても、うまくいくどころか失敗する可能性だってある。
「〇〇を選んで後悔した」というのは、自分の考えなしに、人に言われたことを鵜呑みにしてその通りにやってみたケースが多い気がします。(自分がそうでした。)

ここで大事なのは、やっぱり直感なのだと思います。自分の考えに正直に、自分が良いと思うものを選ぶこと。

  • 自分は惹かれるけれど、うまくいく保証のない選択
  • 自分は腑に落ちないけれど、うまくいった前例の多い選択

成功する確率だけで見れば、後者を選ぶのが正解に思えます。
客観的にはそうなのでしょう。でも、その選択に自分の人生の時間を費やし、そこから得られるものの大きさで考えたとき——自分で納得して選んだことのほうが、たとえ失敗しても得られるものは多いと、思うのです。

自分で選んだことの結果は、他の誰かのせいにできません。だからこそ、成功も失敗もまるごと自分のものになる。誰かの正解をなぞって得た成功より、自分で選んで転んだ経験のほうが、次の選択の糧になる気がしています。

終わりに

選ぶことは、いつだって何かを手放すことです。
だから選択は少し怖いし、ときどき、選ばなかった道のことを思い出す。
結局、何が正しいのかはわからないけど、自分の意思で選択をする。この事実を積み上げていくしかないのかなと思います。
悩んだら最後は自分の直感です。過去を振り返っても、意外とそれが後悔のない選択になっていたように思います。
そんな感じでこれからも、周りの意見よりも自分の意見を大事に、選択をし続けていこうと思います。
最後までお読みいただき、ありがとうございました!

ランニングレース前の準備をまとめるiOSアプリ「Running Race Mate」を作りました

はじめに

こんにちは。趣味のランニング関連のアプリを開発・リリースしました!
開発したのは、レース前の準備をレースごとにまとめて管理できるiOSアプリ「Running Race Mate」です。

アプリの配布URLはこちらです。もしご興味あれば覗いてみてもらえたら嬉しいです。

Running Race Mate

Running Race Mate

  • Yoshiki Takamatsu
  • ヘルスケア/フィットネス
  • 無料
apps.apple.com


ソースコードも公開しています。

github.com


どんなアプリか

Running Race Mateは、マラソンやハーフマラソン、10kmレースなどに向けた準備を、ひとつのレースプランとして保存するアプリです。

レース名・開催日・スタート時刻・距離・目標タイム・補給ジェル・メモを入力すると、次の情報をまとめて確認できます。

  • 1kmあたりの目標ペース
  • 5kmごとの通過タイム
  • 補給ジェルのタイミング
  • 持ち物チェックリスト
  • レース前のメモ
  • レース前日に確認を促すローカル通知

なぜ作ったのか

ランニングのレース前は、走ることそのもの以外の準備も大事です。

目標ペースを確認し、補給を何個持つか決め、ゼッケンや計測チップ、着替えなどを準備して、当日の注意点も見返す。こうした情報を毎回バラバラに管理するより、レース単位でまとまっていたほうが安心できると思いました。

個人的に欲しいなと思っていたのもあります。

開発の流れ

これまでのアプリ開発同様、GitHub Issue で機能を小さく分けて、順番に実装しました。

  • SwiftUIプロジェクトの初期構築
  • レースプランの端末内保存
  • 目標ペース・通過タイム・補給タイミングの計算
  • レース一覧、作成、詳細、編集画面
  • 持ち物チェックリスト
  • レース前のローカル通知
  • 設定、免責事項、プライバシーポリシー
  • テスト、UI調整、App Store提出準備

実装はCodexを中心に進め、Cursorのレビューも使いながら細かな改善を重ねました。

工夫した点

データは端末内に保存する構成にしました。

ログイン、外部サーバー、広告、課金、解析SDKは使っていません。レース準備に必要な情報を気軽に入力でき、外部通信なしで完結します。
意図せずデータが外に出るリスクをなくし、気軽に使える構成を意識しました。

通知まわりは少し丁寧に作りました。

レース前日の20時、スタート2時間前、30分前から必要なタイミングを選べます。レース内容を編集した場合も、すでに登録済みの通知を更新できるようにしています。

学んだこと

  • MVPでは「作らないもの」を先に決めるのが大事

HealthKit連携、GPS計測、SNS共有、Apple Watch対応、クラウド同期などは、今回入れませんでした。レース準備という主目的に集中できました。

  • 小さな計算機能でも、利用シーンまで考えるとアプリになる

ペース計算だけでなく、通過タイム・補給・持ち物・メモを一緒に扱うことで、レース前に開きたくなる形に近づけられたと思います。

  • 通知は見た目以上に状態管理が必要

通知の再登録、キャンセル、編集後の更新などを考えると、単に通知を追加するだけでは不十分でした。実際の利用フローを想像して実装する大切さを学びました。

終わりに

Running Race Mateは、レース当日を少しでも落ち着いて迎えるための準備アプリとして作りました。

今後は、実際に使いながら改善したいポイントを探していく予定です。

余った食材で使い切りメニューを提案するWebアプリを作りました

はじめに

こんにちは。前回の AI開発プロンプト整形ツール に続き、毎月(なるべく毎週)何かしらアプリをリリースしていこうという取り組みの第二弾として、使い切りごはん・買い物リストメーカー を作りました。
冷蔵庫に余っている食材や、使い切りたい調味料から「今日なに作ろう?」と迷ったときに、候補をサッと出してくれる Web アプリです。作った過程や工夫した点も含めて紹介します。

アプリのURLは以下です。もし良ければ、軽く触ってみてもらえると嬉しいです。

leftover-meal-planner.vercel.app


どんなアプリか

余っている食材、使いたい調味料、人数、調理器具、気分・目的を選ぶと、条件に近いメニューをスコアリングして、おすすめ上位 3 件を表示します。

各メニューでは、次の情報をまとめて確認できます。

  • 必要な食材(足りないものも含む)
  • 調理手順
  • 保存の目安
  • 翌日の転用案
  • 加熱などの注意点

食材は 1 つ以上選ばないと提案できないようにしてあり、調味料・調理器具・気分は未選択でも動くようにしています。

レシピはアプリ内に 20 件ほどテンプレートとして持っています。AI API は使わず、ブラウザ内のルールベースのスコアリングで候補を出す構成です。

なぜ作ったのか

前回と同様、サクッとデプロイできる Web アプリ を目指したのが大きな理由です。モバイルアプリだと審査が入る分、リリースまでのハードルが上がるので、まずは静的サイトとして出せるものを選びました。

題材は「冷蔵庫の余り物でごはんを決めたい」という、自分の身近な悩みからです。自分はけっこうなめんどくさがりで、毎回ゼロから献立を考えるより、手持ちの食材に合わせて候補が出てくれると助かる、という発想で作りました。(似たような考えの人もきっと多いはず・・)

開発の流れ

前回と同じく、GitHub Issue で作るものを小さく分けて進めました。設計メモで開発範囲を先に決め、Issue 単位で実装していく形です。

おおまかな進め方は次のとおりです。

  • プロジェクト初期構築(Vite + React + TypeScript)
  • 画面構成・共通レイアウト
  • 入力フォーム
  • レシピテンプレート作成
  • スコアリングロジック
  • 提案結果表示
  • 免責・プライバシーポリシーページ
  • SEO の最低限の設定
  • レスポンシブ調整・動作確認・デプロイ

開発で使った AI は、前回と同様 Codex と Cursor です。役割分担も同じで、Codex で実装、Cursor でレビュー という進め方にしました。Cursor の Bugbot を PR に連携させ、細かい指摘を先に拾うようにしています。

工夫した点

前回と共通する部分として、Issue 単位のタスク管理 と AI 中心の開発フロー が効きました。Issue に要件が書いてあるので、AI 側から直接文脈を読ませやすく、細かい指示の往復が減りました。

今回アプリ固有の工夫としては、次の点です。

  • AI を使わずルールベースで提案する — API キーやコストを気にせず、最小構成で早く出せる
  • 「使い切り」に寄せた表示 — 保存目安や翌日の転用案まで出すことで、食事を作ったあとも無駄なく活かせる提案内容とした
  • スマホ幅を意識した UI — 食材選択と結果表示が崩れないよう、主要導線を先に固めた

学んだこと

  • 「作らないリスト」を先に決めると速い — ログインや AI 連携を最初から入れないと判断しておいたおかげで、実装の迷いが減りました。
  • ルールベースでも「提案アプリ」は作れる — スコアリングが単純でも、食材・気分・調理器具を組み合わせれば、それなりに「それっぽい」候補は出せます。精度を上げるならレシピ数の拡充が先かな、と感じました。AI API 経由でよりリッチな体験もアリですが、費用の問題も出てくるので今回はそこまで手を出しませんでした。
  • 前回の開発フローをそのまま再利用できた — Issue 駆動 + Codex 実装 + Cursor レビューの型が定着してきて、二作目は立ち上がりが早かったです。
  • Cursor は API 利用上限がすぐ来るーこれはけっこう痛かったです。Bugbot に色々とレビューしてもらって有用な指摘をしてくれていたのですが、20ドルのプランだと Bugbot レビュー(Bugbot に限らず Automation なども対象)を行うたびにAPI使用容量が積み重なっていき、すぐに上限に来てしまって、もっと使いたい場合は サブスクプランを上げるか、クレジットを追加して従量課金にするか、の選択となりました。
  • そのため、今回は Bugbot のほかに、codex のレビューエージェントを追加して、GitHub のプルリクエスト上で @codex run のようにコメント入れると codex のレビューが走るようにレビュー体制を拡充しました。

終わりに

前回の第一弾から少し時間が空いてしまいましたが、第二弾アプリを公開することができました。
第三弾もリリースに向けて開発を進めています。
以降も継続的に開発を進めていこうと思います。AIを導入することでアウトプットスピードが劇的に上がっていて、この取り組みに大いに活躍してくれています。
引き続き色々なアプリを開発していこうと思うので、もし興味持っていただけたら今後のブログ記事読んでみていただけたら嬉しいです。

AI開発プロンプト整形ツールを作りました

はじめに

こんにちは。ここ最近、一念発起して、毎月、なるべくなら毎週何かしらのアプリをリリースしていこうと思い立ち、いつまで続くかわかりませんが、チャレンジを続けてみようと思います。
今回はそのファーストステップとして、AI開発ツール向けの依頼文をMarkdown形式に整えるWebアプリを作りましたので、アプリの紹介や作った過程などについて書きたいと思います。
アプリのURLは以下です。もし良ければ、軽く触ってみてもらえると嬉しいです。

AI開発プロンプト整形ツール

どんなアプリか

やりたいこと、用途、技術スタック、制約、依頼文の厳しさを入力すると、AIに渡しやすいMarkdownプロンプトを生成します。

対応している用途は、例えば以下のようなものです。

  • 新規アプリ作成
  • バグ修正
  • リファクタリング
  • コードレビュー依頼
  • テスト追加
  • README作成
  • ドキュメント整備
  • 要件整理
  • 調査・比較
  • リリース前チェック
  • GitHub Issue作成
  • PRレビュー依頼

生成したプロンプトはそのままコピーして、Cursor、Codex、Claude Codeなどに貼り付けて使えます。

なぜ作ったのか

理由はまず、毎月(なるべく毎週)アプリをリリースする、という目標を実現するにあたり、サクッとデプロイできるアプリを目指したかったことです。
モバイルアプリだと Apple などのプラットフォーム側の審査のプロセスが入り、どうしても即時のリリースは難しいです。
その点、Web アプリだと今はデプロイも簡略化して簡単にデプロイできる環境が整っており、このアプリリリースの取り組みを始めるにあたって、とっかかりに良さそうだと思ったのと、AIを今後も使っていく上でテンプレ的にプロンプトを作れるツールがあると便利かもと思い、今回アプリを作ってみることにしました。

開発の流れ

まずGitHub Issueで作るものを小さく分けて進めました。
アプリ要件の定義・整理、技術スタックの検討・設計、はじめのプロジェクト初期構成の作成、各種ライブラリの導入、個別画面の作成・・・
1テーマ1Issueの形で管理し、Isssue単位で開発を進めていきました。

開発で使用したAIは、Codex と Cursor です。これはこの2つをサブスク契約しているというのが理由で、この2つじゃないといけなかったというわけではないです。他の AI を契約していたら、たぶんその AI を使っていたと思います。

Codex と Cursor は実装役とレビュー役とで役割を分けました。自分は、Codex で実装、Cursor でレビュー、の開発スタイルで進めました。
Cursor には Bugbot というレビューエージェント機能があり、GitHub で連携させることで、

  • PR 作成時やコミットプッシュ時に自動レビュー
  • PR 上でメンションすることで手動レビュー

のように実行することができます。
Bugbot は今回初めて使いましたが、デッドコードになっている箇所など細かいところまで見てくれて、事前にバグを防いでくれることを期待できそうに思いました。

工夫した点

上記に書いたように、Issue単位でタスクを管理したことと、AI中心の開発フローを構築した点かなと思っています。
自分は Codex や Cursor アプリで開発を進めることが多いですが、アプリに GitHub Plugin をインストールすることで Issue 番号を指定するだけで、
開発を進めさせたり、PR にコメントが入ったらその旨だけ伝えることでレビューコメントを見て適切に実装を修正してくれました。
手動系の動作確認は自分の方で実施しましたが、実装などのタスクはほとんど AI に任せながら開発を進めました。

学んだこと

  • GitHub Issue を中心とした開発スタイルありだなと思いました。Issue を俯瞰してタスクの全体像がわかりますし、AI から直接 Issue を見られるようにしたことで、いちいち細かく指示しなくても済んだことはかなりの時間短縮になりました。
  • AI 中心開発は便利な反面、どうしてもトークン使用量が多くなるので、使い方によってはサブスクプランのUpgradeも検討しないといけないかなと思いました。自分の ChatGPT Proプランの契約を検討中です。

終わりに

最近始めた毎週・毎月リリースの取り組みと、作ったアプリに関して紹介させていただきました。
AI 使って開発はかなり楽になったので、今後は何を作るか、作ると決めたらミニマムで機能・アプリを作り、デプロイしていくようなスピード感ある開発が求められてくるだろうなと思いました。
スピード・質の両方を担保しながらこれからさまざまなアプリを作っていこうと思います。

レビューの修正はレビュイーだけがやるべきなのか?

はじめに

こんにちは。最近レビューについて考えることが増えまして。これまで(そして今も)、レビューで指摘があればレビュイーが修正する、という進め方をしています。もちろんこれが基本で現在もこのやり方をしています。
ただ、AIによって開発速度が大きく上がった今、本当にそれが効率的な進め方なのだろうかと疑問に思う場面が出てきて、少しこのレビューの進め方について考えたことを書いてみたいと思います。

レビューの目的は何か

人によって意見が分かれるところだと思いますが、個人的には、レビューの目的は成果物をブラッシュアップすることだと思っています。
成果物の

  • 品質を上げること
  • より良い設計にすること
  • 読みやすくすること

これらが大事だと思っています。

指摘だけじゃなく自分で修正しちゃってもいいのでは

レビューをしていると、

  • 誤字脱字
  • 命名のニュアンス
  • コメントの表現
  • ドキュメント上の単語・文章の言い回し

このような指摘をすることがあります。
でもこれらって、レビュワー自身の暗黙知や感覚に依存している場合もあると思います。

そういった場合は、

レビュイーが修正 -> 再レビュー -> 何か違和感 -> 再指摘

こんな感じにレビューが長引くことがあります。
そういった場合は、コメントを書いて相手に解釈してもらうより、自分で直した方が早いケースも少なくないと思っています。

レビューラリーは意外とコストが高い

  • コメントを書く。
  • 相手が読む。
  • 修正する。
  • 再レビューする。
  • 問題なければ承認する。

一つひとつは小さな作業ですが、積み重なると意外と大きな認知負荷になります。
特に、本質的ではない指摘で何度もラリーが発生すると、成果物の改善よりもプロセスの維持に時間を使うことになります。
いわゆる、レビューのためのレビューですね。

みんなで成果物を育てる

必ずしもレビュイーだけが修正する必要はないと思っています。
本質的な設計判断や実装意図の確認はレビュイーが対応した方が良いと思っていますが、例えば、

  • 誤字脱字
  • 命名のニュアンス
  • コメントの表現
  • ドキュメント上の単語・文章の言い回し

このような内容は、レビュワー自身が修正してしまっても良いと思っています。
大事なのは誰が直したかではなく、成果物が良くなることです。
レビュー参加者全員で成果物を育てていく。
この意識で取り組むことで、レビュー工数が徒に増加することを防げます。
みんなで良くしている感を共有することで一体感が生まれます。

AI時代だからこそ

AIによって開発速度は今後もさらに上がっていきます。
そうなると、これまで目立たなかったボトルネックが表面化してきます。
その一つがレビュー。

開発速度が上がったのにレビュー工程は従来のままだと、そこがボトルネックになりえます。
だからこそ、「どう指摘するか」だけでなく「どう最短で成果物を良くするか」という視点でレビューの進め方自体を見直していくことが大事になるかもしれません。

終わりに

最近ふと、レビューの進め方で自分自身あまり意識できていなかったことについて書いてみました。
レビューの目的を成果物のブラッシュアップだと考えるなら、修正する人を固定する理由もないように感じています。
アウトプットスピードが求められる時代に色々なアプローチで改善を図っていきたいですね。

iOS, Android 両方開発が辛くなってきた。クロスプラットフォームはこれからまた伸びてくるのか?

はじめに

こんにちは。ここ一ヶ月くらい、iOS, Android の機能開発を一人で担当して進めています。一人で担当するので調整コストは少なくスピーディーに進められる一方で、実装になってくると、採用しているアーキテクチャや細かな実装はそれぞれの OS で異なり、それぞれに適した実装をしていかなければなりません。
AI を使った開発で実装スピード自体は早められるものの、低品質なコードを上げないために、その実装で良いのかの判断が欠かせません。
ぼやきのような内容になりますが、その過程で思った最近の辛みについて書いてみようと思います。

状況

一人で1プロジェクトを担当しています。例えば、〇〇機能をアプリに組み込む、画面Aに△△機能を実装する、などといった単位で、その機能を実現するために必要な領域を全て一人で担当します。その機能に iOS, Android, Backend 開発が必要なのであれば全て担当範囲ということです。
もちろん開発だけを担当するのではなく、企画からリリースまで、全工程を担当します。
PdMやデザイナーと適宜相談しながらプロジェクトの曖昧な部分を明確にしていきつつ、実装をしてテストしてリリースするような流れで進めます。
そんな中で、いま一番実装に関わる時間が長いのが iOS, Android 開発です。
このあたりの実装面で最近課題を感じていて、その言語化をしてみます。

開発の進め方

以下のような流れで進めています。

  • 実現したい機能はプラットフォーム共通であるため、要件が固まったら、まずその要件をもとに、AIに実装計画を立てさせます。
  • 自分とAIとで何度かのラリーの後、実装計画が固まったら、その計画をもとに、AIに実装を依頼します。
  • AIから実装がアウトプットされてくるので、自分でまずセルフレビューして、指摘事項を上げてAIに修正させる、これを繰り返して実装をさせ、動作確認をします。
  • レビュー専門のサブエージェントにコードレビューを依頼します。(自分は各プラットフォームごとに専門特化したサブエージェントを定義しています)
  • サブエージェントからのレビュー指摘があればそれを実装AIに渡して修正させ、自分の方でも修正内容を確認して問題なければ、再度サブエージェントにコードレビューを依頼します。
  • 何度かのラリーの後、サブエージェントからOKが出ればチーム内レビューを依頼します。以降の流れはこれまでと同様にレビュー指摘があれば修正して再レビュー依頼して・・を繰り返していきます。

課題に感じていること

課題はシンプルな言葉で言うと、疲れる・・、ということです。
iOS で上記の流れで開発を行なって、Android でも同じ流れで開発して、Backend や Frontend の開発もあれば同様の流れで開発をして、とにかく常に AI への指示出しとレビューをしています。
特に、同じ機能を実装するのに、iOS と Android でアーキテクチャが異なるため、一方で実装した内容をそのまま使うことができません。考え方や実装方針は一部流用できます。でも、結局どちらも実装しなければならず時間がかかるのです。
これまでは各開発領域で開発担当者が分かれてそれぞれが開発していたので、一人あたりの実装量やコンテキストスイッチの問題も起こりづらかったと思いますが、AI が普及してAIを活用しながら一人で担える領域が広がった今では、常にコンテキストスイッチの切り替えコストに晒されます。
1日の仕事が終わると、そして一週間の仕事が終わると、クタクタなのです。疲れます。

クロスプラットフォームってどうなんだろう?

色々な開発現場を経験してきましたが、SwiftUI, Jetpack Composeのように、宣言的に実装できる言語機能が追加されたこともあり、それ以前よりも実装がしやすくなり、ネイティブらしいUIにもできることから、iOS, Android ネイティブでの開発を意思決定している現場が多い印象です。自分がいま関わっている開発もそうです。
でもそれは iOS 担当、Android 担当、のように分かれていたことも前提の一つとしてあったと思っています。
一人であらゆる領域を担当することも徐々に広がってきている(と思われる)現在の開発環境では、ロジックの共通化、UIの共通化、がまた大事になってくるかも、と予想しています。
それを実現する一つの解がクロスプラットフォームですね。
Flutter や React Native、Kotlin Multiplatform (KMP) などです。
最近 iOS, Android 両方開発することが多いことから、1回の実装で両プラットフォーム対応できたら良いのに・・なんて感じながら実装を進めています。

終わりに

もちろんメリデメや賛否色々あると思いますが、とにかく短いスケジュールでハードコミットしている自分の現状に対する辛みを述べつつ、ぼやいてみました。何か解決策やヒントを提示するような内容ではありませんが、同じような悩みや状況にある方もいらっしゃるのではないかと思います。
そのような方の背中を押すような内容でもありませんが、AI で開発体験そのものが変わろうとしている過渡期において、今後どうなっていくのか楽しみにはしています。たぶんもう以前のようなある程度の人数体制でのチーム開発に戻るようなことはないと想像しているので、一人で開発をするような辛みを経験しそれに慣れていくことが今後エンジニアとして生きていく上で大事な要素の一つになるではないかと感じています。

学習記録:React Native(Expo)— リストと画面一覧表示

日付: 2026-05-10
時間: 約 60 分

⚠️鋭意学習中の内容につき、一部誤りのある可能性があります。もし誤っている内容があったらすぐに修正しますので、お気づきの方はそっとご指摘いただけたらとても喜びます🙇

はじめに

こんにちは。今回は Expo 製のミニアプリ ApiMoviesApp で、JSON から一覧リストを取得し、ロード/エラー/一覧の三状態を MoviesScreen に切り替えながら FlatList で表示するところまでをやりました。取得処理は別モジュールに分け、JSON は ランタイムで検証してから型付きの配列に落とす構成です。

今日の学習教材は以下です。

github.com

今日やったこと
  • MoviesScreenuseStateloading / error / movies を置き、useEffect 内で fetchMovieList() を実行して一覧を描画した(ActivityIndicator・エラー文言・FlatList の分岐)
  • useEffect のクリーンアップで cancelled フラグを立て、アンマウント後に setState が走らないようにした
  • src/api/moviesApi.ts でリモート fetch に失敗した場合や HTTP 異常時に、同梱の assets/movies.json にフォールバックする経路を実装した

学んだこと

1. 副作用内の非同期とクリーンアップ

useEffect から直接 async 関数を返せないので、内部で run を定義して void run() としている。クリーンアップで cancelled を真にしたうえで、成功・失敗・finally いずれでもガードすると、画面遷移後の状態更新競合を避けられる。

2. ネットワーク取得とフォールバック

fetch は接続環境により失敗しうるので、レスポンスの ok チェックと try/catch をセットにするとよいとのこと。

3. unknown 前提のパースと型ガード

API の JSON をそのまま信頼せず、トップレベルがオブジェクトか、movies が配列か、各要素に必須フィールドがあるかを確認してから使う。

ハマったところ・メモ

  • 手元の実機からは https://reactnative.dev/movies.json に接続できなかった。(PCでは接続できた)
    • チュートリアルでは、リモートURL から JSON を取得できなかったらローカルの json ファイルを読み込む形で対処した。

終わりに

今日は React Native を触りました。同時並行で React も学んでいるので、知識が繋がる部分もあって相乗効果があって良いです。React Native 独自のコンポーネントもあって混乱しますが・・。Reducer 周りの知識をつけたいと思うので今後学習したいと思います。