React – エンジニア見習い https://otonan-syusyoku.work 三流プログラマー Tue, 28 Oct 2025 05:24:52 +0000 ja hourly 1 https://wordpress.org/?v=7.0.3 https://otonan-syusyoku.work/wp-content/uploads/2023/10/cropped-名称未設定のデザイン-16-32x32.png React – エンジニア見習い https://otonan-syusyoku.work 32 32 Laravel+Inertia+ReactをECSで動かしたい！ NginxとPHP-FPMのコンテナ分離 https://otonan-syusyoku.work/archives/2153 https://otonan-syusyoku.work/archives/2153#respond Tue, 28 Oct 2025 05:24:52 +0000 https://otonan-syusyoku.work/?p=2153 Laravel + Inertia (React/Vue) の組み合わせは、SPA（シングルページアプリケーション）の体験とサーバーサイド（Laravel）の書きやすさを両立できる、非常に強力な構成です。

しかし、ローカルのDocker Compose環境では問題なく動作しても、AWSのECS Fargateのような本番環境にデプロイしようとすると、いくつかの疑問に直面します。

  • 「NginxとPHP-FPMコンテナはどう連携させるのがベスト？」
  • 「fastcgi_pass ってローカルと設定を変える必要ある？」
  • 「InertiaでビルドしたReactのJS/CSSファイルは、結局どのコンテナに置くのが正解？」

この記事では、fastcgi_pass の基本から、ECS Fargateでの最適なコンテナ構成、そしてInertia/Reactプロジェクト特有の「静的ファイルの配置場所」問題までを、順を追って解説します。

fastcgi_pass とは？

NginxとPHP-FPMの「橋渡し」

まず基本のおさらいです。Nginxは高性能なWebサーバーですが、それ自体はPHPコードを実行できません。
一方、PHP-FPMはPHPコードを実行することに特化したプロセス（サーバー）です。

Nginxがクライアント（ブラウザ）から .php ファイルへのリクエストを受け取ったとき、そのリクエストをPHP-FPMに処理してもらう必要があります。

このとき、Nginxの設定ファイル（nginx.conf）で、「どのPHP-FPMに処理を依頼するか」の宛先を指定するのが fastcgi_pass ディレクティブです。

location ~ \.php$ {
    # ...
    # ↓ この一行が「橋渡し」の指定
    fastcgi_pass php-fpm-server:9000; 
}

 

ローカル開発 (Docker Compose) での構成

ローカル開発では、「1コンテナ1責務」の原則に従い、NginxとPHP-FPMを別々のコンテナとして docker-compose.yml で定義するのが一般的です。

# docker-compose.yml (抜粋)
version: '3'
services:
  # Nginxコンテナ
  nginx:
    image: nginx:alpine
    ports:
      - "80:80"
    volumes:
      - ./nginx.conf:/etc/nginx/conf.d/default.conf
      - ./laravel-project:/var/www/html

  # PHP-FPMコンテナ
  php:
    build: . # PHP-FPMとLaravelコードを含むDockerfile
    volumes:
      - ./laravel-project:/var/www/html

 

この構成では、NginxコンテナとPHPコンテナは 別々のネットワーク空間 に存在します。Docker Composeが提供する内部ネットワークを介して、サービス名で通信します。

したがって、NginxコンテナからPHPコンテナへは、php というサービス名（ホスト名）を使ってアクセスします。

# nginx.conf (Docker Compose用)
location ~ \.php$ {
    # ...
    # 'php' サービス（コンテナ）の 9000番ポートに転送
    fastcgi_pass php:9000;
}

 

（※ このTCP/IP通信によるパフォーマンスやセキュリティの懸念は、コンテナ間通信がDockerの内部ネットワークに限定されていれば、実用上ほとんど問題になりません。）

【1タスク2コンテナ】本番 (ECS Fargate) での構成：

さて、本題のECS Fargateです。
ECSでは、docker-compose.yml に相当するものとして「タスク定義 (Task Definition)」を使います。

ここで重要なキーポイントは、「1つのタスク定義の中で、NginxコンテナとPHP-FPMコンテナの2つを定義する」ことです。

これら2つのコンテナは、1セットで「Webアプリケーションサーバー」として機能します。

ECS Fargateでのfastcgi_passはどうなる？

ECSの同一タスク内で実行されるコンテナは、同じネットワーク空間（ネットワークモード awsvpc）を共有します。

これは、Nginxコンテナから見ると、PHP-FPMコンテナが「他人」ではなく、「自分自身（localhost）」として見えることを意味します。

したがって、ECS Fargate用のNginxイメージに含める nginx.conf の設定は、以下のようになります。

# nginx.conf (ECS Fargate用)
location ~ \.php$ {
    # ...
    # サービス名ではなく、localhost (127.0.0.1) を指定する
    fastcgi_pass 127.0.0.1:9000;
}

 

タスク定義のイメージ

タスク定義では、以下のように設定します。

  • コンテナ-A: php-fpm-container
    • イメージ: （Laravelコードを含むPHP-FPMイメージ）
    • ポートマッピング: なし (外部に公開する必要はないため)
  • コンテナ-B: nginx-container
    • イメージ: （設定済みのnginx.confと静的ファイルを含むNginxイメージ）
    • ポートマッピング: 80:80 (ALBからのトラフィックを受け取るため)

ALB（ロードバランサー）からのトラフィックはNginxコンテナが受け取り、必要に応じて localhost:9000 を介してPHP-FPMコンテナに処理を渡します。

Inertia/Reactのビルドファイルはどこに置く？

ここで、Inertia/React構成特有の問題に直面します。

「InertiaはLaravel（PHP）がビューを配信する仕組みだから、npm run build で生成された public/build フォルダは、PHP-FPMコンテナにだけ置けば良いのでは？」

これはよくある誤解ですが、パフォーマンスと責務分離の観点から、ビルドした静的ファイル（JS/CSS）はNginxコンテナに配置するのが正解です。

この理由を理解するために、Inertiaのページが読み込まれる2段階のフローを見てみましょう。

ステップ1: HTMLシェルのリクエスト (PHP-FPMが処理)

  1. ブラウザが https://example.com/dashboard にアクセスします。
  2. ALB → Nginxコンテナがリクエストを受け取ります。
  3. NginxはこれがPHPのリクエストだと判断し、fastcgi_pass 127.0.0.1:9000 を使ってPHP-FPMコンテナに転送します。
  4. PHP (Laravel) が起動し、Inertiaは app.blade.php をレンダリングしようとします。
  5. このとき、PHPは public/build/manifest.json を読み取り、HTMLに含めるべきJS/CSSのファイル名を特定します。
  6. PHPは以下のようなHTMLの「ガワ」を生成し、Nginx経由でブラウザに返します。 

    <html>
<head>
    <script src="/build/assets/app.12345.js" defer></script>
    <link rel="stylesheet" href="/build/assets/app.67890.css">
</head>
<body>
    <div id="app" data-page="..."></div>
</body>
</html>

ステップ2: 静的アセット(JS/CSS)のリクエスト (Nginxが処理)

  1. ブラウザは、ステップ1で受け取ったHTMLを解析します。
  2. 「/build/assets/app.12345.js と /build/assets/app.67890.css が必要だ」と判断し、ブラウザは別途2回のリクエストをサーバーに送信します。
  3. このリクエストは、もはやPHPとは全く関係ありません。
  4. ALB → Nginxコンテナがこの2つのリクエストを受け取ります。
  5. Nginxは「自分の管理下（public フォルダ）にそのファイルがあるか？」を探します。
  6. Nginxコンテナに public/build/ 以下の実体ファイルが存在するため、NginxはPHP-FPMを起動することなく、それらの静的ファイルを超高速でブラウザに直接返します。

もし、NginxコンテナにJS/CSSファイルがなければ、このリクエストもPHP-FPMに転送されてしまい、「JSファイルを取得するためだけにLaravelを起動する」という深刻なパフォーマンスボトルネックが発生します。

CI/CDでのベストプラクティス

上記2ステップから、CI/CDパイプラインでDockerイメージをビルドする際は、以下の構成が最適です。

  1. npm run build を実行し、public/build ディレクトリを生成します。
  2. PHP-FPMイメージのビルド:
    • Laravelのコード（app/, routes/ など）をコピーします。
    • ステップ1のために public/build/manifest.json をコピーします。（リンク生成に必要）
  3. Nginxイメージのビルド:
    • nginx.conf をコピーします。
    • ステップ2のために public フォルダ全体（index.php と、public/build 以下の 全てのJS/CSSファイル を含む）をコピーします。（静的アセットの配信用）

結論

manifest.json はPHP-FPMコンテナに、JS/CSSの実体ファイルはNginxコンテナに必要です。

両方のイメージに public フォルダ（または public/build）全体をコピーするのが、最もシンプルで確実な方法です。

まとめ

ECS Fargateで Laravel + Inertia + React 構成を動かすための要点をまとめます。

  1. 構成: 「1タスク2コンテナ（Nginx + PHP-FPM）」構成を採用します。
  2. fastcgi_pass: NginxからPHP-FPMへの通信は、同一タスク内のため fastcgi_pass 127.0.0.1:9000; を指定します。
  3. 静的ファイル: ビルドしたJS/CSSは、パフォーマンス最適化のためNginxコンテナに配置し、Nginxから直接配信させます。
  4. manifest.json: HTMLシェル生成のため、PHP-FPMコンテナにも manifest.json が必要です。

この構成により、PHP-FPMは動的処理に専念し、Nginxは静的ファイルの高速配信に専念するという、「1コンテナ1責務」のメリットを最大限に活かした、スケーラブルな本番環境を構築できます。

]]> https://otonan-syusyoku.work/archives/2153/feed 0 RESTful APIとSPAの関係についてReactとPHPで解説します https://otonan-syusyoku.work/archives/1674 https://otonan-syusyoku.work/archives/1674#respond Sun, 25 Feb 2024 12:40:20 +0000 https://otonan-syusyoku.work/?p=1674 RESTful APIとは？

What`s up

RESTful APIは、ウェブアプリケーションやウェブサービスで使われるプログラミングインターフェースです。
REST（Representational State Transfer）の原則に基づいて設計されており、ウェブ上のリソースへのアクセスや操作を統一的な方法で提供します。
リソースはURLで識別され、HTTPメソッド（GET、POST、PUT、DELETEなど）を使ってアクセスされます。

[getpost id=”1672″ cat_name=”1″ date=”0″]

SPA（シングルページアプリケーション）とは？

SPAは、ユーザーがアプリケーションを操作する際にページの再読み込みをせずに、必要なデータのみをサーバーから非同期に取得し、動的にページの内容を更新するウェブアプリケーションの形式です。

これにより、従来のマルチページアプリケーションに比べてユーザーエクスペリエンスが向上します。

僕が所属しているチームでもページのリロードが嫌だというユーザーの使用感からSPAへの移行が少しづつ始まってきています。
世間的にもSPAは流行っていますよね。（流行っているから偉いというわけではない。知ることが大事

RESTful APIとSPAの関係性

Let`s GO

SPAでは、ページの初回読み込み時にアプリケーションの全てのコード（HTML、CSS、JavaScript）がロードされます。

その後のユーザーの操作によってデータが必要になる場合、SPAはRESTful APIを通じてサーバーからデータを非同期に取得します。
このデータはJSONやXML形式で返され、JavaScriptを用いてクライアントサイドで処理され、ページの一部分だけが動的に更新されます。

このアーキテクチャにより、SPAはユーザーにスムーズで反応の良いインターフェイスを提供できます。

RESTful APIはこのプロセスの背後にあるデータ通信の基盤となります。

PHPとReactを使った例

ここでは、PHPで書かれた簡単なRESTful APIと、Reactを使ったSPAの例を示します。

PHPによるRESTful API

PHPで簡単なAPIエンドポイントを作成します。この例では、GETリクエストを受け取り、簡単なJSONデータを返します。

<?php 
    header('Content-Type: application/json');
    $response = ['message' => 'Hello, world!'];
    echo json_encode($response); 

    // Response
    //{"message": "Hello, world!"} ?>

このPHPスクリプトは、サーバーに配置してのようにアクセスするとJSONが返されます。

ReactによるSPA

Reactで簡単なSPAを作成し、上記のAPIからデータを取得して表示します。

import React, { useState, useEffect } from 'react';
import axios from 'axios';

function App() {
  const [message, setMessage] = useState('');

  useEffect(() => {
    axios.get('http://yourserver.com/index.php')
      .then(response => {
        setMessage(response.data.message);
      })
      .catch(error => console.error('There was an error!', error));
  }, []);

  return (
    <div>
      <button>{message}</button>
    </div>
  );
}

export default App;

このコードは、コンポーネントがマウントされた後にAPIからデータを取得し、取得したメッセージを表示します。
React（クライアントサイド）とPHP（サーバーサイド）を使った、RESTful APIとSPAの基本的な連携を示しています。

今回のコードでは、データを取得して表示するだけのコードになっていますが、Event処理などによりリロードされることなく動的にページの内容を変更させることが可能です。

セキュリティとパフォーマンスの考慮

SPA（シングルページアプリケーション）とRESTful APIを使用する際には、セキュリティとパフォーマンスの両方に配慮することが重要です。
以下では、これらの観点から基本的なガイドラインをいくつか紹介します。

セキュリティ

  1. HTTPSを使用する
    データの暗号化を確実に行うため、APIとの通信には常にHTTPSを使用します。（当たり前です）
    これにより、中間者攻撃（MITM）のリスクを減らすことができます。
  2. CORSポリシーを適切に設定する
    クロスオリジンリソースシェアリング（CORS）ポリシーを適切に設定し、信頼できるオリジンからのリクエストのみを許可します。
    不適切なCORS設定は、セキュリティリスクを招く可能性があります。
  3. 認証と認可
    JWT（JSON Web Tokens）やOAuthなどの堅牢な認証メカニズムを使用して、APIへのアクセスをセキュアに管理します。
    また、ユーザーの権限に基づいてアクセスを制御する認可も重要です。
  4. 入力の検証とサニタイズ
     SQLインジェクションやクロスサイトスクリプティング（XSS）攻撃を防ぐため、サーバー側とクライアント側の両方で入力値の検証とサニタイズを行います。
  5. 依存関係のセキュリティ
    使用するライブラリやフレームワークのセキュリティ脆弱性に注意し、定期的に更新を行い脆弱性を修正します。

この辺の対策については過去に記事にしていますので時間ある人は読んでみてくださーい

[getpost id=”1618″ cat_name=”1″ date=”0″][getpost id=”1256″ cat_name=”1″ date=”0″]

パフォーマンス

  1. コードの分割
    ユーザーが必要とするコードのみをダウンロードするように、コード分割（Code Splitting）を実装します。
    これにより、初期ロード時間を短縮できます。
  2. キャッシュ戦略の利用
    静的リソースやAPIレスポンスのキャッシュを適切に利用することで、パフォーマンスを向上させることができます。
    ブラウザのキャッシュやCDNの利用が有効です。
  3. 遅延ローディング（Lazy Loading）
     画像やコンポーネントなど、必要になるまでロードしないようにします。
    これにより、初期ロードのパフォーマンスを向上させることができます。
  4. APIの最適化
    不必要なデータの送受信を避けるため、APIのレスポンスをできるだけ小さく保ちます。
    また、必要なデータのみを取得するためのフィルタリングやページネーションをAPI側でサポートします。
  5. フロントエンドのパフォーマンス最適化
    Reactなどのフロントエンドフレームワークを使用する場合は、不要な再レンダリングを避け、メモ化（memoization）や仮想DOMの効率的な利用などのテクニックを活用します。

セキュリティとパフォーマンスは、アプリケーションの設計と開発の初期段階から考慮する必要があります。
これらの基本的なガイドラインを実践することで、ユーザーに安全で快適な体験を提供することができます。

]]> https://otonan-syusyoku.work/archives/1674/feed 0 【Tips】Laravel+React-Quillで独自スタイルを適用する方法 https://otonan-syusyoku.work/archives/1575 https://otonan-syusyoku.work/archives/1575#respond Fri, 05 Jan 2024 11:53:19 +0000 https://otonan-syusyoku.work/?p=1575 React-Quill を使用している際にスタイルを少しだけ変更したいといった場面があると思います〜

スタイルを当てる事に焦点を置いているので、UIのダサさは気にしないでください。

そんなときのちょっとしたTipsを紹介します。

完成形

変更前

Quill 変更前

変更後

Quill 変更後

なぜEditorに独自スタイルを当てるのか？

ITリテラシーが低いユーザーに使用してもらうのが、一番の理由です。

殺風景なUIだとその時点でユーザーが離れてしまうことに最近気づきました。

プログラマーやエンジニアをやっている人には理解できないかもしれないのですが、リテラシーの低い人はとことん低いです。

  • 画面が味気ない
  • よくわからないボタン
  • 英語

少し考えたら分かるだろうと怒りたい気持ちもあるのですが、使ってもらえなければただのゴミを作ってしまうことになるので、工夫が必要です。

CSSの定義

Laravel の指定ディレクトリに Quill 用の CSS を用意します。

  • `resources/css/Quill/style.css`
  • Quill 用にディレクトリを切って用意したほうが得策な気がします…
.quill {
    .ql-toolbar {
        background-color: rgb(148 163 184); /* bg-slate-400 */
    }

    .ql-editor {
        h1, h2, h3 {
            padding-left: 0.5rem;
            border-radius: 0.5rem; /** rounded-lg */
            background-color: rgb(56 189 248); /* bg-sky-400 */
            color: white;
            margin-bottom: 1.2rem;
        }

        p {
            font-size: 1rem;
            margin-bottom: 1.2rem;
        }
    }
}

 

定義したCSSをQuillコンポーネントで読み込み

先ほど定義した CSS をQuill を定義しているコンポーネント内でインポートします。

  • Quill のデフォルトのスタイルを上書きするために ‘react-quill/dist/quill.snow.css’ の後にインポートするようにします
import React from 'react';
import ReactQuill from 'react-quill';
import 'react-quill/dist/quill.snow.css';
import '@/../css/Quill/style.css';

export default function QuillEditor({ handleValueChange, value }) {
    const customToolbarOptions = [
        ['bold', 'italic', 'underline', 'strike'],        // toggled buttons
        ['link', 'image'],
        ['blockquote', 'code-block'],

        [{ 'header': 1 }, { 'header': 2 }],               // custom button values
        [{ 'list': 'ordered' }, { 'list': 'bullet' }],
        [{ 'script': 'sub' }, { 'script': 'super' }],      // superscript/subscript
        [{ 'indent': '-1' }, { 'indent': '+1' }],          // outdent/indent
        [{ 'direction': 'rtl' }],                         // text direction

        [{ 'size': ['small', false, 'large', 'huge'] }],  // custom dropdown
        [{ 'header': [1, 2, 3, 4, 5, 6, false] }],

        [{ 'color': [] }, { 'background': [] }],          // dropdown with defaults from theme
        [{ 'font': [] }],
        [{ 'align': [] }],

        ['clean']    
    ];

    // 親コンポーネントから受け取った関数を使って、inputの値を渡す
    const handleContentValueChange = (content) => {
        handleValueChange(content);
    };

    return (
        <ReactQuill
            theme="snow"
            value={value} // 親コンポーネントから受け取った値を設定
            onChange={handleContentValueChange}
            modules={{
                toolbar: customToolbarOptions,
            }}
        />
    );
}

 

ReactQuill素晴らしい

ReactQuillをメンテナンスしてくれている方たちに感謝を伝えたいです。

すごくお世話になっています。ありがとう。

]]> https://otonan-syusyoku.work/archives/1575/feed 0 【Laravelプロジェクト】react-image-galleryを導入 https://otonan-syusyoku.work/archives/1396 https://otonan-syusyoku.work/archives/1396#respond Sat, 26 Aug 2023 09:02:54 +0000 https://otonan-syusyoku.work/?p=1396 技術構成
Laravel Laravel Framework 10.15.0
React react-dom@18.2.0
DaisyUi daisyui@3.5.0
tailwind @tailwindcss/forms@0.5.4

いい感じなフォトギャラリーないのか

HP作成を行っているとスライダーの要望が度々出てくるはずです。

かくいう僕も今回、そういった要望があってスライダーを導入しなければいけない状態でした。

 

一度、jQueryで生実装したことがあるのですが、なんやかんや面倒くさい思いをした苦い経験があったので、今回は生実装を避けたいという思いからReact でいい感じなライブラリないのか調べたところ「react-image-gallery」に出会いました。

 

天下のReact 様は流石だなと言う感じです。

react-image-gallery以外の選択肢としては以下のようなものが挙げられます。

react-image-gallery https://github.com/xiaolin/react-image-gallery
画像のスライドショーを作成するための高機能なライブラリ
react-images https://github.com/jossmac/react-images
シンプルなカスタマイズ可能なグリッドスタイルのイメージギャラリーを作成するためのライブラリ
react-awesome-lightbox https://github.com/photostory/react-awesome-lightbox
モーダルウィンドウ内で画像を表示するためのライブラリ

 

実際に導入

npm でインストール。

npm install react-image-gallery

 

インポート

import ImageGallery from 'react-image-gallery';
import 'react-image-gallery/styles/css/image-gallery.css';

※2行目のcss もインポートしてください。
　css もインポートすることで梱包されているスタイルを当てることが可能です。

 

上記の設定で使う準備が完了です。

あとは自由に設定していくだけです。

 

今回はLaravel からデータを渡すため、コントローラーから配列を渡します。（本当はModel でデータ定義して渡すべきですが、）

$images = [
            [
                "original" => "/img/AsItFlows/asit_team.jpg",
                "thumbnail" => "/img/AsItFlows/asit_team.jpg",
                "originalAlt" => "チーム",
                "thumbnailAlt" => "チーム",
                "onErrorImageURL" => "/img/AsItFlows/logo.jpg",
            ],
            [
                "original" => "/img/AsItFlows/sunset.jpg",
                "thumbnail" => "/img/AsItFlows/sunset.jpg",
                "originalAlt" => "サンセット",
                "thumbnailAlt" => "サンセット",
                "onErrorImageURL" => "/img/AsItFlows/logo.jpg",
            ],
            [
                "original" => "/img/AsItFlows/surf_member.jpg",
                "thumbnail" => "/img/AsItFlows/surf_member.jpg",
                "originalAlt" => "メンバー",
                "thumbnailAlt" => "メンバー",
                "onErrorImageURL" => "/img/AsItFlows/logo.jpg",
            ],
            ...
        ];
        shuffle($images);
        return Inertia::render('Public/AsItFlows/Top', [
            'items' => $images
        ]);

 

最後にjsx 側でいい感じに使用します。

<ImageGallery items={items}
  showNav={true}
  autoPlay={true}
  showFullscreenButton={false}
  useBrowserFullscreen={false}
  showPlayButton={false}
/>

 

 

んー。素敵。

 

 

]]> https://otonan-syusyoku.work/archives/1396/feed 0 [React] useStateとuseEffectってすごく便利じゃん https://otonan-syusyoku.work/archives/1382 https://otonan-syusyoku.work/archives/1382#respond Thu, 17 Aug 2023 16:17:59 +0000 https://otonan-syusyoku.work/?p=1382 今までjQueryで戦ってきたのですが、とうとう見切りをつけて次のステップに進もうとしているコテツです…

Reactの考え方

React では、DOM 要素を直接操作する代わりに、React の状態管理やレンダリング方法を使用して操作を行うことが推奨されているとのこと。

useState

useState フックは、状態（state）を React コンポーネント内で管理するために使用します。状態は、コンポーネント内でのデータの変更を追跡し、自動的に再レンダリングするために使われます。

差分取って差分の分だけレンダリングするっぽいですね。楽だし早いね。

Reactの基本理念？である状態管理で差分を取るってのがuseStateの肝な気がする。

useEffect

コンポーネントのレンダリング後に実行される処理(データ)を管理するために使用します。

useEffect フックは第1引数に副作用の関数を受け取り、第2引数には、依存する値の配列を指定します。この配列に指定した値が変更された場合に副作用関数が再実行されます。

空の配列を指定することで、初回レンダリング時にのみ副作用関数が実行されることを意味します。

    const [csrfToken, setCsrfToken] = useState(null);
    useEffect(() => {
        // メタタグからトークンを取得
        const metaTag = document.querySelector('meta[name="csrf-token"]');
        if (metaTag) {
            setCsrfToken(metaTag.content);
        }
    }, []);

なんとなくonloadっぽい。。。

注意点

第二引数に何も指定しない

無限ループ発生します。ローカル端末が燃えます。気をつけましょ。

]]> https://otonan-syusyoku.work/archives/1382/feed 0 Docker+Laravel+React+Viteで環境構築し、npm run dev で画面真っ白 https://otonan-syusyoku.work/archives/1377 https://otonan-syusyoku.work/archives/1377#respond Sat, 22 Jul 2023 05:19:52 +0000 https://otonan-syusyoku.work/?p=1377 画面真っ白に

表題の通り、Docker+Laravel+React+Viteで環境構築後にnpm run dev で画面が真っ白になってしまった。

バージョン
Docker 
docker --version
Docker version 20.10.6, build 370c289
Laravel 
php artisan --version
[22-Jul-2023 14:05:32 Asia/Tokyo] Xdebug: [Step Debug] Could not connect to debugging client. Tried: host.docker.internal:9000 (through xdebug.client_host/xdebug.client_port).
Laravel Framework 10.15.0
React 
npm list --depth=0
data@ /data
+-- @headlessui/react@1.7.15
+-- @inertiajs/react@1.0.9
+-- @tailwindcss/forms@0.5.4
+-- @vitejs/plugin-react@3.1.0
+-- autoprefixer@10.4.14
+-- axios@1.4.0
+-- laravel-vite-plugin@0.7.8
+-- postcss@8.4.27
+-- react-dom@18.2.0
+-- react@18.2.0
+-- tailwindcss@

 

エラー文言

デベロッパーツール＞Console

GET http://127.0.0.1:5173/@vite/client net::ERR_CONNECTION_REFUSED
localhost/:25     GET http://127.0.0.1:5173/resources/js/app.jsx net::ERR_CONNECTION_REFUSED
localhost/:25     GET http://127.0.0.1:5173/resources/js/Pages/Welcome.jsx net::ERR_CONNECTION_REFUSED
localhost/:20     GET http://127.0.0.1:5173/@react-refresh net::ERR_CONNECTION_REFUSED

 

portがおかしい

ConsoleのリクエストURLからportがおかしいことに気づく。

Dockerのnginxで指定していたportは8080:80にしていたのだが、http://127.0.0.1:5173となっている。

 

うーん。なぜだ。

解決方法

Laravel,Reactを導入しているコンテナの設定が漏れている気がしてきた。

Dockerにてアプリケーションコンテナにportをしてみると解決できた。

docker-compose.ymlに以下を追記。

app:
    build: ./docker/php
    volumes:
      - ./src:/data
    ports:
    - 5173:5173  ←vite用port開通

 

そして、viteがホストを参照するようにするため、package.jsonに以下を追記。

"scripts": {
        "dev": "vite --host",   ←--hostを追記
        "build": "vite build"
    },

 

これで解決できた−

 

]]> https://otonan-syusyoku.work/archives/1377/feed 0