"use client";

import type { ReactNode } from "react";
import type { AutoQueueKind } from "yt-dlp-transcript-common/jobs/autoQueueState";
import type { AutoQueueStatusPayload } from "yt-dlp-transcript-common/views/autoQueueStatus";
// Type-only: syncRow.ts is a server module. See OperationRail.
import type { SyncRowView } from "../syncRow";
import FocusBanner from "../../channels/components/FocusBanner";
import EndFocusButton from "../../channels/components/EndFocusButton";
import { HowPriorityWorks } from "./HowPriorityWorks";
import { OperationRail } from "./OperationRail";
import { RunnerOperationView } from "./RunnerOperationView";
import { railStates } from "./railStates";
import { useHydrated, useOperationsStatus } from "./useOperationsStatus";
import { RUNNER_TITLE, type Channel } from "./dispatch";
import { StateBand } from "../../components/pipelines/StateBand";
import { RunningJobsList } from "../../jobs/components/RunningJobsList";
import type { JobRowView } from "yt-dlp-transcript-common/views/jobRowView";

// ONE OPERATION, IN FULL.
//
// THE RAIL IS STILL AT THE TOP, and that is not decoration either: on this
// corpus the normal case is that a lane is idle BECAUSE another one is, so the
// answer to "why is this operation not moving" is usually on a different row.
// It was the switcher's context when the switcher was a <select>; it is the
// same context now that the switcher is a set of links.
export function OperationDetail({
  id,
  initial,
  channels,
  platforms,
  bucketsByKind,
  activeJobs,
  runnerKind,
  sync,
  cadenceConsole,
  dependsOn,
  operationSettings,
  laneSettings,
  channelWork,
}: {
  id: string;
  initial: AutoQueueStatusPayload;
  channels: Channel[];
  platforms: string[];
  bucketsByKind: Record<AutoQueueKind, string[]>;
  // Jobs on this operation's queues, SSR-rendered. Empty renders nothing at
  // all (RunningJobsList returns null), so a quiet page carries no second
  // in-flight list beside the lane's own.
  activeJobs: JobRowView[];
  // THE LANE THAT DISPATCHES THIS OPERATION, or null for one nothing here
  // drives. Resolved on the server by `pauseLaneFor`, which reads the
  // descriptor rather than the id — so an operation the registry gains gets the
  // right answer without a branch in this file.
  runnerKind: AutoQueueKind | null;
  // The rail's sync row, for the rail at the top of every operation page.
  sync: SyncRowView;
  // THE CADENCE-TRIGGERED OPERATION'S CONSOLE, built on the server off
  // `op.trigger` — never off the id. A cadence operation has no backlog to
  // sweep and no runner to start, so its console is its schedule; `runner`
  // cannot say this because it is typed to the AutoQueueKinds and the sync
  // heartbeat is not one of them.
  cadenceConsole?: ReactNode;
  // This operation's declared inputs, labelled. Only rendered when there is no
  // console — where it is most of what the page has to say.
  dependsOn: { id: string; label: string }[];
  // THE FORM FOR THIS OPERATION'S SETTINGS BLOCK, and the form for its LANE's
  // block — both built on the server (they need getSettings and the digest app
  // list) and passed in as slots, so this client component never learns which
  // operation has which block. Which one an operation gets is decided from the
  // descriptor's `settingsBlock`, in page.tsx.
  //
  // Two props rather than one because they are two scopes: `operationSettings`
  // belongs to THIS operation, while `laneSettings` belongs to the shared queue
  // and is therefore the same form on every member page of that lane.
  operationSettings?: ReactNode;
  laneSettings?: ReactNode;
  // THE CHANNELS WITH THIS OPERATION'S WORK, built on the server (it needs the
  // actionable census and `primaryAction` is a function, so it cannot be a
  // client component). Rendered BELOW the console, and OUTSIDE it on purpose:
  //   - inside the runner's <section> it would be a nested <section>, which
  //     RunnerOperationView's contract forbids;
  //   - inside the sweep's <section> its headings, prose and slugs would land
  //     inside every `section[data-lane]`-scoped getByText in the e2e suite.
  // Below rather than above because the console IS the operation; this table is
  // what is waiting for it.
  channelWork?: ReactNode;
}) {
  const { data, refresh } = useOperationsStatus(initial);

  return (
    <div className="flex flex-col gap-6">
      <OperationRail
        bands={data.lanes.bands}
        states={railStates(data)}
        selectedId={id}
        sync={sync}
      />

      {/* ONE CONSOLE, and it is the runner's. Until slice 1.3 this page drew two
          — the runner's and the sweep panel's — so that an operator
          mid-migration could see which one was driving. The sweeps are gone;
          `<section data-lane>` is the contract all four lanes share, and it is
          the only lane section on the page.

          THE LANE CONTEXT IS ABOVE IT, not inside: this operation's own band,
          and the sentence saying which other operations share the lane's queue
          and pause. Outside the runner's <section> because nothing inside it
          may be a <section> and because those headings would land inside every
          `section[data-lane]`-scoped lookup in the e2e suite. */}
      {runnerKind && (
        <>
          {/* ONLY ON AN OPERATION LANE. `bucketsByKind` is empty for exactly the
              two lanes whose work list is an operation's ids rather than a
              snapshot bucket (`selectableBucketsForKind` returns [] for them, by
              construction and permanently), and this block is about THIS
              OPERATION — its band, its switched-off state, its siblings on the
              queue. On auto-transcribe and auto-download the page IS the lane,
              there are no siblings, and "switched off" would be a sentence about
              a membership list those lanes do not have. */}
          {bucketsByKind[runnerKind].length === 0 && (
            <LaneOperationContext
              id={id}
              lane={runnerKind}
              data={data}
              activeJobs={activeJobs}
            />
          )}
          <HowPriorityWorks compiled={data[runnerKind].policyCompiled} />
          {/* THE FOCUS BANNER, OUTSIDE THE LANE SECTION. RunnerOperationView
              opens the page's one `<section data-lane>` and its contract
              forbids a nested <section> and reserves role="status"; the banner
              is neither, and it sits above rather than inside so a
              `section[data-lane]`-scoped lookup in the suite never sees it.

              Its numbers are THIS LANE's: `focusPending`/`otherPending` are
              sums over the lane's own compiled `pendingByLeaf`, so the same
              focus reads differently on the four consoles — which is the point,
              since a focus can be holding one lane and exhausted on another.
              It renders nothing at all when no focus resolves.

              END FOCUS IS HERE, not a link to go and find it. The banner's
              `endFocus` slot takes a control from a caller that can reach the
              ONE writer, and `EndFocusButton` posts `endFocusAction` — the
              same named gesture /channels' focus bar posts. A console is where
              an operator watches a focus drain, so it is where the click that
              ends it belongs; the "Channel priorities" link beside it is still
              the way to everything else. */}
          <FocusBanner
            summary={data[runnerKind].focus}
            name={data[runnerKind].focusName ?? undefined}
            lane={runnerKind}
            endFocus={<EndFocusButton />}
          />
          <RunnerOperationView
            kind={runnerKind}
            title={RUNNER_TITLE[runnerKind]}
            status={data[runnerKind]}
            channels={channels}
            platforms={platforms}
            buckets={bucketsByKind[runnerKind]}
            operations={data.lanes.operations[runnerKind].map((op) => op.id)}
            runsOn={data.lanes.runsOn[runnerKind]}
            onRefresh={refresh}
          />
          {/* Operation block first, lane block second — this operation's own
              switches, then the shared queue's. Both are plain <form>s with
              their own actions, so saving one cannot read the other's
              checkboxes as off. */}
          {operationSettings}
          {laneSettings}
        </>
      )}

      {!runnerKind && cadenceConsole && (
        // The settings slot is drawn here rather than inside the console: the
        // console is a moved component with its own contract, and this keeps
        // "console, then this operation's settings" the same order every other
        // operation page uses.
        <>
          {cadenceConsole}
          {operationSettings}
        </>
      )}

      {!runnerKind && !cadenceConsole && (
        // STILL THE FALLTHROUGH, for a registered operation nothing drives.
        // A cadence console is a third arm, not a replacement for this one.
        <NoConsoleView id={id} data={data} dependsOn={dependsOn} />
      )}

      {channelWork}
    </div>
  );
}

// WHAT THIS PAGE'S OPERATION IS, beside the lane console that dispatches it.
//
// The lane below is SHARED — every operation on one queue is dispatched by one
// runner and held by one gate — and this says so rather than letting a
// per-operation page imply a per-operation switch. What IS this operation's
// alone is the band: its own five populations, its own denominator, its own
// cost basis. That is the figure the shared console cannot draw, because a lane
// holding three operations has no single total that means anything.
//
// A <div>, never a <section>: the runner console below is the page's one
// `section[data-lane]`, and a second section here would be matched by
// `locator("section", { has: heading })` and break every scoped lookup on
// strict mode. `data-operation` names which operation the page is about, which
// the lane cannot say.
function LaneOperationContext({
  id,
  lane,
  data,
  activeJobs,
}: {
  id: string;
  lane: AutoQueueKind;
  data: AutoQueueStatusPayload;
  activeJobs: JobRowView[];
}) {
  const hydrated = useHydrated();
  const band = data.lanes.bands.find((b) => b.id === id) ?? null;
  const operations = data.lanes.operations[lane];
  // The other operations this lane would dispatch, named. Not a count: "shares
  // a lane with 2 others" is exactly the sentence that made "Backfill" mean
  // three different costs.
  const siblings = operations.filter((op) => op.id !== id);
  // In the CATALOG but not on the lane: the operation is registered and
  // switched off. Worth a sentence, because everything else on this page — a
  // running lane, a work list, a claim ladder — would otherwise read as "ready".
  const switchedOn = operations.some((op) => op.id === id);

  return (
    <div
      data-operation={id}
      data-hydrated={hydrated ? "true" : undefined}
      className="flex flex-col gap-4"
    >
      {band && (
        <div className="flex flex-col gap-2 rounded-lg border border-border bg-card px-4 py-3">
          <StateBand band={band} size="rail" />
        </div>
      )}

      {!switchedOn && (
        <p className="text-sm text-warning">
          This operation is switched off in its settings below, so nothing
          dispatches it — its lane will pick every other operation on the queue
          and skip this one. That is not the same as being finished, which is
          what an empty work list would otherwise imply.
        </p>
      )}

      {siblings.length > 0 && (
        <p className="text-sm text-muted-foreground">
          This operation shares one lane, one runner and one pause with{" "}
          {joinLabels(siblings.map((s) => s.label))}. A rule below that names no
          operation claims all of them, not just this one — and the counts have
          different cost bases, so read the rules before starting the lane.
        </p>
      )}

      <RunningJobsList jobs={activeJobs} />
    </div>
  );
}

// AN OPERATION WITH NO CONSOLE HERE — registered, real, and dispatched by
// nothing this page can drive.
//
// The page it replaces was the reason this whole step exists. Before it, an
// operation with no runner and no sweep lane fell through to the backfill
// lane's console: its band, its plan, its scope, and a live START button that
// would have armed THE BACKFILL SWEEP — a corpus-scale GPU commitment — under
// this operation's heading. A console for the wrong lane is worse than none,
// because every control on it works.
//
// So this says the four true things instead: what state the corpus is in (the
// band), what has to happen first (dependsOn), what one video costs (the cost
// basis), and — in a
// sentence taken from the descriptor's own hint — what does dispatch it. That
// last one is why `hint` is worth keeping honest: it is the whole answer here.
function NoConsoleView({
  id,
  data,
  dependsOn,
}: {
  id: string;
  data: AutoQueueStatusPayload;
  dependsOn: { id: string; label: string }[];
}) {
  const hydrated = useHydrated();
  const band = data.lanes.bands.find((b) => b.id === id) ?? null;

  return (
    <section
      // NO data-lane, deliberately: there is no lane, and emitting one would
      // let a test scope lane controls to a page that has none.
      data-operation={id}
      data-no-console="true"
      data-hydrated={hydrated ? "true" : undefined}
      className="flex flex-col gap-4"
    >
      {band && (
        <div className="flex flex-col gap-2 rounded-lg border border-border bg-card px-4 py-3">
          <StateBand band={band} size="rail" />
        </div>
      )}

      <div className="flex flex-col gap-2 rounded-lg border border-border bg-card px-4 py-3">
        <h2 className="font-display text-sm font-semibold tracking-tight">
          Not dispatched from here
        </h2>
        <p className="text-sm text-muted-foreground">
          Neither auto-queue runner nor either sweep lane runs this operation,
          so there is nothing on this page to start or hold. The figures above
          are the corpus state; see the description at the top of the page for
          what does dispatch it.
        </p>
        {dependsOn.length > 0 && (
          <p className="text-sm text-muted-foreground">
            Needs{" "}
            {joinLabels(dependsOn.map((d) => d.label))} first — a video without
            that is counted under &ldquo;needs re-acquiring&rdquo;, not under
            work that is ready.
          </p>
        )}
      </div>
    </section>
  );
}

// "A", "A and B", "A, B and C". Written out because the sentence it lands in is
// the one that keeps an operator from reading a per-operation page as a
// per-operation switch.
function joinLabels(labels: string[]): string {
  if (labels.length <= 1) return labels[0] ?? "";
  return `${labels.slice(0, -1).join(", ")} and ${labels[labels.length - 1]}`;
}