@dxos/app-toolkit - v0.16.0
    Preparing search index...

    Type Alias CardMasonryData

    Surface data for the card-masonry role.

    type CardMasonryData = {
        attendableId?: string;
        CardMenu?: ComponentType<CardMenuData<Obj.Unknown>>;
        detailOf?: string;
        inline?: boolean;
        objects: ReadonlyArray<Ref.Ref<Obj.Unknown>>;
        pending?: ReadonlyArray<CardMasonryPending>;
        size?: "default" | "compact";
    }
    Index

    Properties

    attendableId?: string

    The plank the grid renders in, so a card's actions resolve against the right node.

    CardMenu?: ComponentType<CardMenuData<Obj.Unknown>>

    The host's items for each card's menu, alongside the object's own: rendered once per card, it renders nothing and registers its items with the card's menu via useMenuContribution — the same contract as a type's CardMenu surface, so a host adds actions such as removing the object from its list without the card knowing what they mean.

    detailOf?: string

    Clicking a card opens its object as this plank's detail rather than as a plank beside it.

    inline?: boolean

    In the host's flow rather than in a scroller of its own: for a host that already scrolls, such as a section of an article, where a nested scroller would also pad and centre the grid.

    objects: ReadonlyArray<Ref.Ref<Obj.Unknown>>

    What to show, in reading order. Refs rather than objects: a stack renders what a host holds a link to, and resolving them is the surface's job, so a cold load fills in rather than reading empty.

    pending?: ReadonlyArray<CardMasonryPending>

    Placeholder cards, after the resolved ones, for objects the host is still adding.

    size?: "default" | "compact"

    compact renders the cards at three quarters of their size, so a companion-width host fits two columns where full-size cards would stack in one.