/*
 * Cloudflare Workers operate as serverless functions, executing JavaScript, WebAssembly, or other languages
 * directly on Cloudflare's global network of data centers. They intercept HTTP requests,
 * process them, and return a response, all within milliseconds at the network's edge.
 * This initial worker script demonstrates a basic 'Hello World' response.
 */

// Define a simple event listener that triggers when a request is made to the Worker.
addEventListener('fetch', event => {
  // The 'event.respondWith()' method tells the Worker to intercept the request and respond with a custom response.
  // This response can be static content, dynamic data, or a proxied request to another origin.
  event.respondWith(handleRequest(event.request));
});

/**
 * Handles incoming requests to the Worker.
 * @param {Request} request The incoming HTTP request object.
 * @returns {Promise<Response>} A promise that resolves to an HTTP response.
 */
async function handleRequest(request) {
  // Log the incoming request URL for debugging purposes.
  console.log(`Incoming request for: ${request.url}`);

  // Construct and return a simple text response.
  // The Response object allows setting status, headers, and body content.
  return new Response('Hello from Cloudflare Workers!', {
    status: 200, // HTTP status code for OK
    headers: { 'Content-Type': 'text/plain' } // Specify the content type of the response body
  });
}

/*
 * To deploy this Worker:
 * 1. Ensure you have 'wrangler' CLI installed: `npm install -g wrangler`
 * 2. Create a 'wrangler.toml' file in your project root with your account details and worker name.
 *    Example 'wrangler.toml':
 *    name = "my-react-worker"
 *    main = "src/index.js" # Or wherever your worker script is located
 *    compatibility_date = "2023-01-01"
 * 3. Run `wrangler deploy` from your terminal.
 * This will upload your Worker script to Cloudflare, making it accessible globally.
 */

/*
 * This Cloudflare Worker script demonstrates how to serve a client-side rendered (CSR) React application.
 * It primarily focuses on serving static assets (HTML, CSS, JS) from Cloudflare Pages or R2/KV storage
 * and routing all non-asset requests back to the main index.html for React Router to handle.
 *
 * To use this, you would build your React application (`npm run build`) and then upload the `build` directory
 * contents to Cloudflare Pages or R2. The Worker then acts as the routing layer.
 */

// Import necessary modules from the 'workers-types' package for better type safety.
// This is typically added via `npm install --save-dev @cloudflare/workers-types`
// and configured in `tsconfig.json`
// import type { Request, Response, ExecutionContext } from '@cloudflare/workers-types';

// We'll use a simple proxy to an origin for demonstration. In a real scenario, this would be Cloudflare Pages
// or R2 bucket URL where your React static assets are hosted.
const STATIC_ASSETS_ORIGIN = 'https://your-cloudflare-pages-site.pages.dev'; // REPLACE WITH YOUR ACTUAL PAGES URL or R2 endpoint

addEventListener('fetch', event => {
  event.respondWith(handleRequest(event.request));
});

async function handleRequest(request) {
  const url = new URL(request.url);

  // Define a set of file extensions that typically belong to static assets of a React app.
  // This list ensures that actual asset requests are served directly, while others are routed to index.html.
  const staticFileExtensions = [
    '.html', '.css', '.js', '.json', '.webmanifest', '.png', '.jpg', '.jpeg', '.gif', '.svg', '.ico', '.txt',
    '.woff', '.woff2', '.ttf', '.eot', '.map'
  ];

  // Check if the requested path has a static file extension.
  // This heuristic helps distinguish between asset requests and client-side routes.
  const isStaticAsset = staticFileExtensions.some(ext => url.pathname.endsWith(ext));

  // For static assets, directly proxy the request to the origin where they are hosted.
  // Cloudflare's cache will automatically handle caching these assets efficiently.
  if (isStaticAsset) {
    const response = await fetch(`${STATIC_ASSETS_ORIGIN}${url.pathname}`, request);
    // Modify response headers if needed, e.g., to add stricter caching control
    return response;
  }

  // For all other requests (e.g., '/about', '/dashboard'), assume it's a React client-side route.
  // Fetch the 'index.html' from the static assets origin and return it.
  // React Router will then take over on the client-side to render the correct component.
  const response = await fetch(`${STATIC_ASSETS_ORIGIN}/index.html`, request);

  // IMPORTANT: For SPAs, we need to ensure all routes correctly serve index.html.
  // This typically involves cloning the response to modify headers without affecting the original.
  const newResponse = new Response(response.body, response);
  newResponse.headers.set('Cache-Control', 'public, max-age=0, must-revalidate'); // Ensure fresh index.html
  return newResponse;
}

/*
 * Deployment with Cloudflare Pages (Recommended for React SPAs):
 * 1. Build your React app: `npm run build`
 * 2. Connect your Git repository to Cloudflare Pages.
 * 3. Pages will automatically build and deploy your static assets.
 * 4. Configure a 'functions' directory in your Pages project or attach this Worker as a Custom Domain Worker.
 *
 * Deployment with Cloudflare Workers (for more control or custom SSR):
 * 1. `wrangler init my-react-worker --site build` (where 'build' is your React app's build output folder).
 * 2. Modify `wrangler.toml` to serve your static assets: `[site]
 *    bucket = "./build"
 *    entry-point = "worker-entry.js" # Your worker script name for routing logic`
 * 3. Deploy: `wrangler deploy`
 *
 * This example assumes your static assets are served from a known origin (like Cloudflare Pages).
 * For a fully self-contained Worker serving assets from KV or directly from the Worker script,
 * you would use `import { getAssetFromKV } from '@cloudflare/kv-asset-handler';`
 * and configure KV namespaces in `wrangler.toml`.
 */

/*
 * This Worker script demonstrates advanced patterns for a React application, including:
 * 1. Server-Side Rendering (SSR) for a basic React component.
 * 2. Handling a simple API route for dynamic data fetching.
 * 3. Implementing caching for API responses.
 *
 * This example requires a build step for your React app that can generate a server-renderable bundle.
 * For simplicity, we'll use a placeholder for the server-rendered React component logic.
 *
 * To make a React component server-renderable, you would typically use `ReactDOMServer.renderToString()`
 * or `ReactDOMServer.renderToPipeableStream()` from 'react-dom/server' in a server environment.
 * In a Worker, this means bundling your server-side React code into the Worker script.
 */

// Placeholder for server-side React component rendering logic.
// In a real application, this would import your React components and ReactDOMServer.
async function renderReactAppServerSide(urlPath) {
  // Imagine this function renders your React component based on the URL and returns HTML.
  // Example: if urlPath is '/products/123', it fetches product data and renders ProductDetail component.
  const data = { message: `Hello from SSR! Path: ${urlPath}` };
  // In a real scenario, you would dynamically import a server bundle for your React app.
  // const { render } = await import('../build/server/ssr-bundle.js');
  // return render(urlPath, data);
  return `<!DOCTYPE html>
<html>
<head><title>Edge React SSR</title></head>
<body>
    <div id="root"><h1>${data.message}</h1><p>This content was rendered at the edge!</p></div>
    <script src="/static/client-bundle.js"></script>
    <script>window.__INITIAL_DATA__ = ${JSON.stringify(data)};</script>
</body>
</html>`;
}

addEventListener('fetch', event => {
  event.respondWith(handleAdvancedRequest(event.request));
});

async function handleAdvancedRequest(request) {
  const url = new URL(request.url);
  const cache = caches.default; // Access the default Cloudflare cache

  // --- 1. Handle API Routes --- //
  if (url.pathname.startsWith('/api')) {
    const cacheKey = new Request(url.toString(), { headers: request.headers });
    let response = await cache.match(cacheKey); // Try to find a cached response

    if (response) {
      console.log('Serving API from cache:', url.pathname);
      return response;
    }

    // Simulate fetching data from a backend or generating dynamically
    const data = { timestamp: new Date().toISOString(), path: url.pathname, method: request.method };
    response = new Response(JSON.stringify(data), {
      headers: { 'Content-Type': 'application/json' }
    });

    // Cache API responses for 60 seconds. Customize 'Cache-Control' as needed.
    response.headers.set('Cache-Control', 'public, max-age=60');
    event.waitUntil(cache.put(cacheKey, response.clone())); // Store response in cache asynchronously
    console.log('Serving API dynamically (and caching):', url.pathname);
    return response;
  }

  // --- 2. Handle Static Assets (e.g., from a /static path) --- //
  // In a real app, you'd use getAssetFromKV or proxy to R2/Pages.
  if (url.pathname.startsWith('/static/')) {
    // Placeholder: In a real deployment, you'd serve assets from Cloudflare Pages, R2, or KV.
    // Example: const asset = await getAssetFromKV(event, { mapRequestToAsset: req => new Request(new URL(req.url).pathname.replace('/static', ''), req) });
    // return asset;
    return new Response('Static asset content (placeholder)', { headers: { 'Content-Type': 'text/plain' } });
  }

  // --- 3. Handle Server-Side Rendering (SSR) for all other paths --- //
  // If it's not an API call or a static asset, assume it's a React route requiring SSR.
  try {
    const ssrHtml = await renderReactAppServerSide(url.pathname); // Render React on the server
    const response = new Response(ssrHtml, { headers: { 'Content-Type': 'text/html' } });
    console.log('Serving SSR content for:', url.pathname);
    return response;
  } catch (error) {
    console.error('SSR Error:', error);
    // Fallback to a client-side rendered index.html or an error page.
    return new Response('<h1>Application Error: Could not render at the edge.</h1><p>Please try again later.</p>', { status: 500, headers: { 'Content-Type': 'text/html' } });
  }
}

/*
 * Key considerations for advanced deployments:
 * - **SSR Bundling**: Ensure your React application can be bundled for a Node.js-like environment (Workers).
 *   Webpack/Rollup configurations often need adjustments to create a separate server bundle.
 * - **Data Hydration**: Pass initial state from SSR to client-side React for seamless hydration.
 * - **State Management**: Persist user sessions or global state efficiently across requests (e.g., KV, Durable Objects).
 * - **Error Handling**: Robust try/catch blocks are crucial for edge functions.
 * - **Testing**: Utilize `wrangler dev` for local testing and `wrangler tail` for live logging.
 */

/*
 * This example provides a GitHub Actions workflow for deploying a React application
 * and its associated Cloudflare Worker to Cloudflare Pages and Workers.
 * This workflow assumes your React app builds to a 'dist' or 'build' folder
 * and your Worker script is in a 'worker' directory.
 *
 * Prerequisites:
 * - Your repository is connected to Cloudflare Pages for the frontend.
 * - Cloudflare API Token for Workers deployment (scope: Account.Workers, Account.Worker Scripts).
 * - Cloudflare Account ID.
 * - Stored these as GitHub Secrets: CF_API_TOKEN, CF_ACCOUNT_ID.
 */

name: Deploy React App & Cloudflare Worker

on: 
  push:
    branches:
      - main
  workflow_dispatch:

jobs:
  deploy-frontend:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout project
        uses: actions/checkout@v3

      - name: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: 18
          cache: 'npm'

      - name: Install dependencies
        run: npm install

      - name: Build React App
        run: npm run build

      - name: Deploy to Cloudflare Pages
        uses: cloudflare/pages-action@v1
        with:
          apiToken: ${{ secrets.CF_API_TOKEN }}
          accountId: ${{ secrets.CF_ACCOUNT_ID }}
          projectName: your-react-app-name-on-pages # Replace with your Cloudflare Pages project name
          directory: build # The output directory of your React build
          # Git subdirectory if your app is not in the repo root (optional)
          # gitDirectory: 'frontend'

  deploy-worker:
    runs-on: ubuntu-latest
    needs: deploy-frontend # Ensure frontend is deployed first if Worker relies on it
    steps:
      - name: Checkout project
        uses: actions/checkout@v3

      - name: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: 18
          cache: 'npm'

      - name: Install Wrangler CLI
        run: npm install -g wrangler

      - name: Deploy Cloudflare Worker
        run: wrangler deploy --minify --env production
        working-directory: ./worker # Adjust if your worker code is elsewhere
        env:
          CLOUDFLARE_API_TOKEN: ${{ secrets.CF_API_TOKEN }}
          CLOUDFLARE_ACCOUNT_ID: ${{ secrets.CF_ACCOUNT_ID }}
          # Optionally pass environment variables to your Worker during deployment
          # MY_SECRET_API_KEY: ${{ secrets.MY_SECRET_API_KEY }}

/*
 * To adapt this workflow:
 * 1. Replace 'your-react-app-name-on-pages' with your actual Cloudflare Pages project name.
 * 2. Ensure `npm run build` command correctly builds your React application.
 * 3. Adjust `directory: build` if your React build output folder is named differently.
 * 4. Adjust `working-directory: ./worker` to the path where your `wrangler.toml` and Worker script reside.
 * 5. Create `CF_API_TOKEN` and `CF_ACCOUNT_ID` secrets in your GitHub repository settings.
 *    The API Token needs appropriate permissions (e.g., Worker Scripts, Pages).
 */