K.Kojima/ PORTFOLIO

Webアプリ

家計簿アプリ

  • アプリの写真
  • 概要

    家計簿を記録・管理するアプリ

  • 使用技術

    • ・React / Vite
    • ・TypeScript
    • ・Vitest
    • ・React Testing Library
    • ・AWS S3
    • ・AWS CloudFront
    • ・AWS IAM
    • ・OIDC (GitHub Actions)
    • ・GitHub Actions
  • 主な機能

    • ・家計登録
    • ・編集
    • ・削除
    • ・カテゴリごとに表示
    • ・ローカルストレージへ保存
    • ・何個中何個終わった表示
  • 工夫した点 / 学んだこと

    1. State・コンポーネントの責務分離

    当初は親コンポーネントに入力値・一覧データ・保存処理・編集処理など多くの責務が集まり、コンポーネントが300行近くになっていました。そこで、『入力フォーム:入力値の管理』『親コンポーネント:完成したデータの管理』『Custom Hook:Stateや処理の管理』『Pure Function:データ生成・バリデーションなどの処理』というように役割を分離しました。

    <学んだこと>

    「どこにStateを置くか」だけではなく、誰がそのデータの責任を持つのかを考えて設計することの重要性を学びました。

    2. useEffectに頼らない編集フォームの設計

    編集フォームでは当初、useEffectを使って編集対象のデータをStateへ反映していました。しかし、propsとStateの同期処理が必要になり、状態管理が複雑になる課題がありました。そこで、編集対象が決まってからフォームを描画し、keyを利用して編集対象ごとにコンポーネントを再マウントする構成へ変更しました。これにより、フォーム生成時に編集対象の値を初期値としてStateへ設定でき、useEffectによる同期処理を減らしました。

    <学んだこと>

    Stateを後から同期するのではなく、コンポーネントの生成タイミングやライフサイクルを利用して、状態管理をシンプルにする考え方を学びました。

    3. 同じフォームを新規作成・編集で独立して管理

    新規作成フォームと編集フォームでStateを共有していたため、片方への入力がもう一方にも反映される問題が発生しました。そこで、それぞれを独立したフォームとして扱い、編集フォームには編集対象のIDをkeyとして設定しました。これにより、編集対象が変わるたびにフォームが新しいコンポーネントとして生成され、それぞれのStateを独立して管理できるようにしました。

    <学んだこと>

    UI上で隠すだけで問題を解決するのではなく、Stateの所有関係やコンポーネントのライフサイクルから設計を見直すことを意識するようになりました。

    4. CI/CDの責務を分離

    GitHub Actionsでは、CIでLint・Testを実行し、CDではデプロイに必要な処理を行うように役割を分けました。また、CIとCDは別Runnerで実行されるため、ビルド成果物をそのまま共有できないことを実際のエラーを通して理解しました。現在はCD側でもビルドを行っていますが、今後はArtifactを利用してCIで生成した成果物をCDへ渡す構成も検討しています。

    <学んだこと>

    CIとCDでは責務が異なること、またワークフロー間で成果物を受け渡すにはArtifactなどの仕組みが必要であることを学びました。

    5. AWSへのデプロイとセキュリティ

    AWSへのデプロイでは、GitHub ActionsからAWSへアクセスする際にIAM RoleとOIDC認証を利用しました。また、CloudFrontを利用した構成では、デプロイ後にキャッシュが残ることで古いファイルが配信される場合があるため、デプロイ後にキャッシュを削除する処理を自動化しました。

    <学んだこと>

    単にアプリを公開するだけでなく、認証方法やキャッシュなど、本番環境で必要となる仕組みを考慮してデプロイを構成することを学びました。

  • 詳細