import type { Schedule } from 'fhir/r4';

/**
 * - WHICH schedule is the signed-in clinician's own.
 *
 * THE DEFECT: `AppointmentsPage` never referenced the signed-in user at all. The calendar renders only
 * once a practitioner has been picked out of a colleague SEARCH - so **a clinician had to look themselves
 * up by name to see their own week**, and this is the only week view in the product (the overview is
 * today-only).
 * Spencer, 2026-08-14, asked whether Appointments should open on the clinician's own calendar:
 * *"yes it should open on theirs."*
 *
 * Pure, with the role lookup INJECTED, so the rule is testable without the page's twelve contexts - and
 * so it uses the SAME schedulerole resolution the page already uses everywhere else rather than a second
 * one that could disagree about which schedule belongs to whom.
 */

export interface OwnScheduleInput {
    schedules: ReadonlyArray<Schedule>;
    /** The signed-in user's Practitioner id. Absent for a receptionist or admin with no clinical role. */
    practitionerId: string | undefined;
    /** The page's own resolver: schedule -> the PractitionerRole that owns it. */
    practitionerIdForSchedule: (schedule: Schedule) => string | undefined;
}

/**
 * The signed-in clinician's own schedule, or `undefined` when they have none.
 *
 * `undefined` is the ordinary case for a receptionist or an admin who holds no clinical role, and it
 * must leave the picker exactly as it is - this seeds a selection, it never removes one. A page that
 * cleared the picker because the viewer has no schedule would break the colleague search for precisely
 * the roles that depend on it most.
 *
 * Takes the FIRST match deliberately. A practitioner with two blocks (two locations, or in-person and
 * video) has no "primary" recorded anywhere, so any choice here is arbitrary - and opening on one of their
 * own is the whole point, while the picker still reaches the other. Do not invent a ranking; if a
 * primary block is ever a real concept it belongs on the Schedule, not in this heuristic.
 */
export const findOwnSchedule = ({
    schedules,
    practitionerId,
    practitionerIdForSchedule,
}: OwnScheduleInput): Schedule | undefined => {
    if (!practitionerId) return undefined;
    return schedules.find((schedule) => practitionerIdForSchedule(schedule) === practitionerId);
};

/**
 * Should the page seed a selection right now?
 *
 * ONLY WHEN NOTHING IS SELECTED. Re-seeding after the user has chosen a colleague would yank the
 * calendar back to their own the moment the schedule list refreshed - a WebSocket update, a re-fetch -
 * and it would look like the app rejecting their click.
 */
export const shouldSeedOwnSchedule = (
    hasSelection: boolean,
    alreadySeeded: boolean,
): boolean => !hasSelection && !alreadySeeded;