import type { ReactNode } from "react";

/**
 * ONE CARD OF SECTIONS, NOT A STACK OF CARDS.
 *
 * An opened practice used to draw each of its four parts in its own bordered card, so the body read as
 * four things that happened to be near each other. The deck draws one card divided by hairlines under
 * small-caps labels, and the difference is not decoration: **the card IS the practice.** Locations,
 * access, people and appointments are facets of one participant in the patient's record, and boxing
 * each of them separately says they are four subjects.
 *
 * THE LABEL CARRIES ITS COUNT rather than leaving the reader to count rows - "4 UPCOMING VISITS", not
 * "Appointments at this organization" over a list you have to tally. A count in a heading is the
 * cheapest thing a screen can tell somebody, and it is the answer they came for.
 *
 * The hairlines are the PARENT's (`divide-y` on the card in `OrgDetailBody`), so a section that renders
 * nothing draws no divider either - which is what lets `OrgInfoSection` return null without leaving a
 * line across the card.
 */
export const OrgSection = ({
    label,
    count,
    children,
}: {
    label: string;
    /** Rendered in front of the label when the section knows its own size. */
    count?: number;
    children: ReactNode;
}) => (
    <section className="ahr-practice-sec-body">
        {/*
          * THE APP'S OWN SMALL-CAPS LABEL, not the deck's pixel values retyped.
          *
          * The deck draws `.pd-h` at 11px with `letter-spacing:.06em`. Asking for those directly
          * renders neither: this build emits ARBITRARY utilities bare, `(0,1,0)`, and the base rule for
          * an `h4` under the mount id is `(1,0,1)` - so `text-[11px]` loses and the heading paints at
          * the app-wide heading size. The source reads correct and the screen does not, which is the
          * one failure a code review cannot catch.
          *
          * `text-xs font-medium uppercase tracking-wide text-secondary` is the same combination six
          * other surfaces already use for this exact label - the onboarding task focus, the chat's
          * section heads, the questionnaire answers. Matching the app's own step beats matching the
          * deck's pixel to the unit.
          *
          * AND IT IS A `p`, WHICH IS THE OTHER HALF OF MATCHING THEM - measured in the running mount
          * rather than reasoned:
          *
          *     <h4 class="... tracking-wide">   ->  letter-spacing -0.12px
          *     <p  class="... tracking-wide">   ->  letter-spacing  0.3px
          *
          * `.tracking-wide` is emitted BARE at `(0,1,0)` and `#...root h1,h2,h3,h4,h5,h6` sets
          * `-0.01em` at `(1,0,1)`, so on a heading the utility loses and the label renders TIGHTER than
          * body text where the deck wants it looser. ⛔ A NAMED utility is not automatically safe: what
          * makes one safe is being id-scoped, and this one is not. The arbitrary-utility guard does not
          * catch it, because the utility is not arbitrary.
          *
          * The six surfaces that already draw this label all use a `p` or a `div`, and every one of
          * them is right for this reason. The element was the whole difference.
          */}
        {/* Now an id-scoped named rule (.ahr-practice-sec-h), so the deck's 11px and .06em land. */}
        <p className="ak-caption ahr-practice-sec-h">
            {typeof count === "number" && (
                // The count is NOT letter-spaced: a number spaced like a label stops reading as a number.
                <span className="ahr-practice-sec-n">{count}</span>
            )}
            {label}
        </p>
        {children}
    </section>
);

export default OrgSection;