import { Badge } from '@/components/badge';
import { Button } from '@/components/button';
import { Spinner } from '@/components/spinner';
import { Switch } from '@/components/switch';
import { Tooltip, TooltipContent, TooltipTrigger } from '@/components/tooltip';
import { InfoIcon, MoonIcon, SunIcon } from '@/icons';
import { useBridge, useFigmaMode } from '~/figma/use-figma';
import { LANG_LABELS, LANGS, type Messages, isLang, useLang, useMessages } from '~/i18n';
import { useParam } from '~/router';
import { Segmented } from './segmented';
import { useA11y, useA11yMode } from '../hooks/use-a11y';

/**
 * Global toggles. They live in the URL hash rather than in React state so a
 * particular view — dark theme, a given page — is a link you can send someone.
 *
 * All three are kit components, which is the rule for the site's chrome. The
 * playground's controls are the deliberate exception, and `playground.tsx` says
 * why.
 */

/* Only the tint is fixed here — both the short word in the pill and the
   sentence in the tooltip come from the catalogue, keyed by the same name. */
const STATUS: Record<
  string,
  { palette: 'green' | 'yellow' | 'black'; key: keyof Messages['toolbar']['bridge'] }
> = {
  live: { palette: 'green', key: 'live' },
  'no-plugin': { palette: 'yellow', key: 'noPlugin' },
  off: { palette: 'black', key: 'off' },
  idle: { palette: 'black', key: 'idle' },
};

/**
 * The bridge indicator, and the switch that turns it off.
 *
 * It was one button doing both jobs; a Switch says which of the two states you
 * are in before you read anything, and the pill beside it reports what the
 * bridge actually answered — those are different facts, and conflating them is
 * why "off" and "running but nothing polling it" used to look alike.
 *
 * Rendered in development only, like `A11yToggle` below and for the same
 * reason: `useBridge` refuses to poll in a built site, so the switch there
 * would be a control that reports nothing and changes nothing.
 */
function FigmaToggle() {
  const [mode, setMode] = useFigmaMode();
  const bridge = useBridge();
  const m = useMessages();

  const status = bridge.enabled ? bridge.status : 'idle';
  const tone = STATUS[status] ?? STATUS.off;
  /* Switched on but never probed is the one state with nothing to report yet,
     so it gets the spinner rather than a word that would be wrong a moment
     later. Switched *off* reports as `idle` too, which is why `enabled` has to
     be in the test — that state is settled, not pending. */
  const probing = bridge.enabled && bridge.status === 'idle';

  return (
    <Tooltip>
      <TooltipTrigger asChild>
        <label className="cbar-pill">
          <Switch
            size="sm"
            checked={mode !== 'off'}
            onCheckedChange={(next) => setMode(next ? 'live' : 'off')}
            aria-label={m.toolbar.figma}
          />
          <span className="hidden sm:inline">{m.toolbar.figma}</span>
          {probing ? (
            <Spinner className="size-3.5" label={m.toolbar.status.probing} />
          ) : (
            <Badge size="xs" variant="subtle" colorPalette={tone.palette}>
              {m.toolbar.status[tone.key]}
            </Badge>
          )}
        </label>
      </TooltipTrigger>
      <TooltipContent className="max-w-xs">
        {m.toolbar.bridge[tone.key]}
        {bridge.file ? (
          <>
            <br />
            {m.toolbar.file}: {bridge.file}
          </>
        ) : null}
      </TooltipContent>
    </Tooltip>
  );
}

/**
 * The axe switch — the same shape as the Figma one, and present only in
 * development.
 *
 * `import.meta.env.DEV` is a literal at build time, so this whole component and
 * everything it reaches (including the dynamic `import('axe-core')`) is dropped
 * from a production `showcase:build` rather than merely hidden. `?a11y=on`
 * would do nothing in a built site, which is why there is no control for it
 * there either.
 */
function A11yToggle() {
  const [mode, setMode] = useA11yMode();
  const a11y = useA11y();
  const m = useMessages();

  const total = a11y.violations.reduce((sum, violation) => sum + violation.nodes.length, 0);

  return (
    <Tooltip>
      <TooltipTrigger asChild>
        <label className="cbar-pill">
          <Switch
            size="sm"
            checked={mode === 'on'}
            onCheckedChange={(next) => setMode(next ? 'on' : 'off')}
            aria-label={m.toolbar.a11y}
          />
          <span className="hidden sm:inline">{m.toolbar.a11y}</span>
          {/* Nothing at all while off: a zero here would claim a clean page
              that was never audited. */}
          {a11y.status === 'running' ? (
            <Spinner className="size-3.5" label={m.a11y.running} />
          ) : a11y.status === 'ready' ? (
            <Badge size="xs" variant="subtle" colorPalette={total > 0 ? 'red' : 'green'}>
              {total > 0 ? total : m.a11y.clean}
            </Badge>
          ) : null}
        </label>
      </TooltipTrigger>
      <TooltipContent className="max-w-xs">{m.toolbar.a11yHint}</TooltipContent>
    </Tooltip>
  );
}

/**
 * Three segments rather than a `<select>`: at two characters each the whole set
 * costs less width than a collapsed dropdown, and the current language stays
 * visible next to the alternatives instead of behind a click.
 *
 * On `chrome/ui/segmented.tsx` rather than on the kit's `Tabs` — that file says
 * why, and the short version is that a language switch controls no tab panel.
 * `isLang` still guards the value: `Segmented` is generic over the option type
 * but its `onChange` is only as narrow as what it was handed.
 */
function LangSwitch() {
  const [lang, setLang] = useLang();
  const m = useMessages();

  return (
    <Segmented
      label={m.common.language}
      values={LANGS}
      value={lang}
      onChange={(next) => {
        if (isLang(next)) setLang(next);
      }}
      renderValue={(option) => LANG_LABELS[option]}
      itemProps={(option) => ({ lang: option })}
    />
  );
}

export function Toolbar({ onStartTour }: { onStartTour: () => void }) {
  const [theme, setTheme] = useParam('theme', 'light');
  const m = useMessages();
  const dark = theme === 'dark';

  return (
    /* Two groups, not five loose controls: the switches on the left are about
       the page you are inspecting, the three on the right about how you are
       looking at the site. The divider is what says so — without it the row
       read as a queue of unrelated widgets, which is why the eye had to check
       all of them every time.
       The tour opens that right-hand group rather than joining the left one:
       it is not scoped to the page you happen to be on, and it is the control
       a first-time visitor is most likely to want, so it comes first among the
       three. */
    <div className="flex items-center gap-2">
      {import.meta.env.DEV ? <A11yToggle /> : null}
      {import.meta.env.DEV ? <FigmaToggle /> : null}

      <span aria-hidden="true" className="mx-1 hidden h-5 w-px bg-border sm:block" />

      <Tooltip>
        <TooltipTrigger asChild>
          <Button
            variant="outline"
            colorPalette="black"
            size="icon-sm"
            onClick={onStartTour}
            aria-label={m.tour.reopen}
          >
            <InfoIcon />
          </Button>
        </TooltipTrigger>
        <TooltipContent>{m.tour.reopen}</TooltipContent>
      </Tooltip>

      <Tooltip>
        <TooltipTrigger asChild>
          <Button
            variant="outline"
            colorPalette="black"
            size="icon-sm"
            onClick={() => setTheme(dark ? 'light' : 'dark')}
            aria-label={dark ? m.toolbar.light : m.toolbar.dark}
          >
            {dark ? <SunIcon /> : <MoonIcon />}
          </Button>
        </TooltipTrigger>
        <TooltipContent>{dark ? m.toolbar.light : m.toolbar.dark}</TooltipContent>
      </Tooltip>

      <LangSwitch />
    </div>
  );
}