import { useState, type ReactNode } from "react";
import { Card } from "../../../components/ui/card";
import { Button } from "../../../components/ui/button";
import {
  AlertDialog,
  AlertDialogContent,
  AlertDialogHeader,
  AlertDialogTitle,
  AlertDialogDescription,
  AlertDialogFooter,
  AlertDialogCancel,
} from "../../../components/ui/alert-dialog";
import { STATE_LABELS } from "../../../services";
import type { CollaborationTeam, RemovedTeamMember, TeamMembership, MemberActionType } from "../../../services";
import { formatDate } from "../../../utils/dateUtils";
import { MemberIdentity } from "./MemberIdentity";
import { MemberAffiliation } from "./MemberAffiliation";

type TeamWithMembers = CollaborationTeam & { members: TeamMembership[] };

interface TeamMembersSectionProps {
  team: TeamWithMembers;
  memberAction: (teamId: string, memberRef: string, action: MemberActionType) => Promise<TeamMembership>;
  onChanged: () => Promise<void>;
  /**
 * THE CONTROL THAT ACTS ON THIS LIST, RENDERED AT THE END OF IT.
 *
 * Invite lived in the page header, which is where a control goes when nobody has asked where it
 * BELONGS. The deck puts it at the bottom right of the members section, and the rule underneath
 * that is the one the referrals rail already states: a control belongs where the thing it acts on
 * is. A patient thinking "who else should be here" is looking at the list of who is here.
 *
 * A SLOT RATHER THAN THE DIALOG ITSELF, because the dialog needs five services this section has
 * no business knowing about - and a section that reached for them would be a members list that
 * can also invite, which is two jobs.
 */
  footer?: ReactNode;
  /** The signed-in viewer's own references, so a removal they made reads "by you". */
  viewerRefs?: string[];
}

// Who removed a member, in the reader's terms; nothing when the server did not record it.
const removedBy = (removal: RemovedTeamMember, patientId: string, viewerRefs: string[]): string => {
  if (!removal.removedByRef) return "";
  if (viewerRefs.includes(removal.removedByRef)) return " by you";
  if (removal.removedByRef === `Patient/${patientId}`) return " by the patient";
  // A team member may take back an outside invitation they or a colleague sent.
  if (removal.removedByRef.startsWith("Practitioner/")) return " by a team member";
  return " by someone acting for the patient";
};

// Shows every non-pending member of the team (invited/active). Members awaiting the owning
// patient's own approval live in PendingApprovalsSection instead, so a member row never appears in
// both sections at once. The owning patient can remove any member here; the server enforces
// whether that's actually valid for the member's current state.
//
// REMOVAL ASKS FIRST. Remove used to fire on the single press that reached it: one click and the
// person was off the team, with nothing said before and nothing offered after. This is the screen
// where a patient decides who may read their record, the rows sit inches apart, and a member's
// name may still be resolving when the pointer arrives - so the press that lands is not reliably
// the press that was meant. The confirm is the settled convention for a destructive action, and
// it earns its place here twice over: it also states WHO is about to be removed, resolved through
// the same identity the row uses, which is the only thing that makes two similar rows tellable
// apart at the moment it matters.
//
// Mirrors TeamLifecycleSection: the destructive action is a plain Button inside the dialog rather
// than AlertDialogAction, so a failed removal does not slam the dialog shut on its way to the
// error line.
export const TeamMembersSection = ({ team, memberAction, onChanged, footer, viewerRefs = [] }: TeamMembersSectionProps) => {
  const members = team.members.filter((member) => member.state !== "pending-patient-approval");
  const removed = team.removedMembers ?? [];
  const [busy, setBusy] = useState<boolean>(false);
  const [error, setError] = useState<string | null>(null);
  // The member the patient has asked to remove and not yet confirmed. Holding the membership
  // itself rather than a boolean is what lets the dialog name the person it is asking about.
  const [pendingRemoval, setPendingRemoval] = useState<TeamMembership | null>(null);

  const handleRemove = async (member: TeamMembership) => {
    setBusy(true);
    setError(null);
    try {
      await memberAction(team.teamId, member.memberRef, "remove");
      await onChanged();
      setPendingRemoval(null);
    } catch {
      setError("Failed to remove this member. Please try again.");
      setPendingRemoval(null);
    } finally {
      setBusy(false);
    }
  };

  return (
    <Card className="team-section-card ak-card--flat p-4 space-y-3">
      {/* THE DECK WRITES A SECTION HEADING AS A LABEL, not as a title: 11px, uppercase, letter-
          spaced, in the muted ink. That is what keeps the NAMES the biggest thing in the section,
          which is the whole point of a list somebody scans for a person.

          The deck's own colour here is --faint and this takes the muted step instead. --faint is
          3.06:1 on --paper and our token file says in as many words that it is for large text and
          borders only; an 11px label is neither. Everything else is the deck's, verbatim. */}
      <p className="team-section-label ak-caption">Members</p>
      {error && <p className="text-sm text-destructive">{error}</p>}
      {members.length === 0 ? (
        <p className="text-sm text-secondary">{removed.length > 0 ? "No current members." : "No members on this team yet."}</p>
      ) : (
        <div className="space-y-2">
          {members.map((member) => (
            <div
              key={member.memberRef}
              className="team-member-row flex items-start justify-between gap-3"
            >
              <div className="team-member-who min-w-0 space-y-1">
                <MemberIdentity
                  memberRef={member.memberRef}
                  memberClass={member.memberClass}
                  displayName={member.displayName}
                />
                {/* WHERE THEY ARE FROM, directly under the name. A team crossing three practices
                    was three sets of identical-looking rows, and this is the row somebody reads
                    before pressing Remove. */}
                <MemberAffiliation
                  memberRef={member.memberRef}
                  memberClass={member.memberClass}
                  organizationDisplays={member.organizationDisplays}
                  specialtyDisplays={member.specialtyDisplays}
                />
                {member.role && <p className="text-xs text-secondary">{member.role}</p>}
              </div>
              {/* THE STATE IS A WORD AT THE END OF THE ROW, not a bordered token on a line of
                  its own. It was an outline Badge under the affiliation, which gave a three-line
                  row where the deck has two and put a boxed word directly beneath the practice -
                  so a member's PRACTICE and their MEMBERSHIP STATE, two unrelated facts, stacked
                  into what reads as one block of detail about them.

                  The deck's row has two ends: who they are on the left, what is true of them on
                  the right, in the same slot its invite sheet puts an Invite control in. Every
                  row on this screen then has its answer in the same place. */}
              <div className="team-member-end flex items-center gap-2 shrink-0">
                <span className="team-member-state text-xs text-secondary">
                  {member.memberClass === "related-person"
                    ? "Added"
                    : STATE_LABELS[member.state]}
                </span>
                {/* QUIET AT REST, AND THE RED LIVES ON THE CONFIRM.

                    This was built as Deny's twin - same slot, same red ghost - because refusing
                    somebody the record and taking it back are the same act at two moments. That is
                    true of the PAIR and it does not survive the COUNT, which is the half nobody
                    asked until the screen was looked at: Deny appears ONCE, on a pending row, and
                    Remove appears on EVERY row. Eight red-bordered buttons ran down the right edge
                    of a page whose job is to say who is on your team, and they were the loudest
                    thing on it.

                    THE PORTAL HAS NEVER DRAWN A REPEATED DESTRUCTIVE CONTROL, counted across the
                    patient-portal decks: one red button per frame and never two. Family and
                    caregivers is the closest analogue there is - a list of people the patient may
                    remove - and it reaches removal from a frame of its own rather than from a
                    column of buttons.

                    AND THE SLOT'S OWN RULE SAYS IT: the deck styles this position
                    `font-size:11px; color:var(--faint)`. It built the slot QUIET. Approve and Deny
                    override that because their row is asking for a decision; the steady state is a
                    word. So Remove keeps the slot and loses the paint, and the red is on the
                    confirm's destructive half - which is where the decision is actually taken, and
                    leaves the button standard exactly as it was: the colour is still the purpose,
                    applied where the purpose is exercised. */}
                <Button
                  className="team-member-remove btn btn-stripped text-xs"
                  size="sm"
                  disabled={busy}
                  onClick={() => setPendingRemoval(member)}
                >
                  Remove
                </Button>
              </div>
            </div>
          ))}
        </div>
      )}

      {removed.length > 0 && (
        <div className="space-y-2" data-testid="team-removed-members">
          <p className="team-section-label ak-caption">Removed</p>
          {removed.map((removal) => (
            <div key={removal.memberRef} className="team-member-row">
              <div className="team-member-who min-w-0 space-y-1">
                <MemberIdentity memberRef={removal.memberRef} memberClass={removal.memberClass} displayName={removal.displayName} />
                <p className="text-xs text-secondary">
                  {`Removed ${formatDate(removal.removedAt)}${removedBy(removal, team.patientId, viewerRefs)}`}
                </p>
              </div>
            </div>
          ))}
        </div>
      )}

      {footer && <div className="flex justify-end">{footer}</div>}

      <AlertDialog
        open={pendingRemoval !== null}
        onOpenChange={(open) => {
          if (!open && !busy) setPendingRemoval(null);
        }}
      >
        <AlertDialogContent>
          <AlertDialogHeader>
            <AlertDialogTitle>Remove this member from the team?</AlertDialogTitle>
            <AlertDialogDescription asChild>
              <div className="space-y-2">
                {pendingRemoval && (
                  <div className="space-y-1">
                    <MemberIdentity
                      memberRef={pendingRemoval.memberRef}
                      memberClass={pendingRemoval.memberClass}
                      displayName={pendingRemoval.displayName}
                    />
                    {/* THE CONFIRM NAMES THE PRACTICE TOO, and this is the place it earns its
                        keep most: the whole reason the dialog states who it is asking about is
                        that two similar rows sit inches apart, and for two colleagues with
                        similar names the practice is the only thing that separates them. */}
                    <MemberAffiliation
                      memberRef={pendingRemoval.memberRef}
                      memberClass={pendingRemoval.memberClass}
                      organizationDisplays={pendingRemoval.organizationDisplays}
                      specialtyDisplays={pendingRemoval.specialtyDisplays}
                    />
                  </div>
                )}
                <p>
                  They leave &ldquo;{team.name}&rdquo; immediately and lose its shared conversation and the
                  record access this team granted.{" "}
                  {pendingRemoval?.memberClass === "related-person"
                    ? "You can add them back at any time from Invite someone."
                    : pendingRemoval?.memberClass === "external-practitioner"
                      // An empty practice list is the server saying they belong to no practice: they
                      // came in by email and NPI, and that is the way back.
                      || (pendingRemoval?.memberClass === "practitioner" && pendingRemoval.organizationDisplays?.length === 0)
                      ? "You can invite them again from Invite someone with their email and NPI, and they will need to accept."
                      // A named practice says nothing about which; the appointment route is any practice's.
                      // Practices that could not be read promise no route at all.
                      : pendingRemoval?.organizationDisplays?.length
                        ? "You can invite them again if you have a past or upcoming appointment with them. Otherwise, another team member can invite them, and you approve it."
                        : "Bringing them back takes a new invitation, which they will need to accept."}
                </p>
              </div>
            </AlertDialogDescription>
          </AlertDialogHeader>
          <AlertDialogFooter>
            <AlertDialogCancel className="btn btn-amber" disabled={busy}>
              Keep them on the team
            </AlertDialogCancel>
            {/* THE CONFIRM'S OWN BUTTON HAD TO BE PAINTED TOO, and it is the same trap the
                new-team button was: a variant does not survive the portal's button reset, which
                zeroes background, border and colour at id specificity. So the destructive action
                stood as bare text next to a filled amber Keep - the emphasis exactly backwards
                from what the two buttons do. */}
            <Button
              className="btn btn-red"
              disabled={busy || !pendingRemoval}
              onClick={() => {
                if (pendingRemoval) void handleRemove(pendingRemoval);
              }}
            >
              {busy ? "Removing..." : "Remove"}
            </Button>
          </AlertDialogFooter>
        </AlertDialogContent>
      </AlertDialog>
    </Card>
  );
};

export default TeamMembersSection;