Surface API visuals · 5 of 7

Six ways to compose

AttachA resource holds a child structure at the key body, inside a wall of its own. the resource title type body its own frame value format

Attach

attach($key, Child::class)

A fixed child: its keys are stored as a map under the key, behind the wall, and refined and validated in its own frame.

VariantsThe sibling key plugin, set to my_teaser, chooses the my_teaser structure at the key settings; the site branding block's structure is not chosen. the resource plugin: my_teaser chooses settings site branding not chosen my_teaser headline limit

Variants

attachVariants($key, by: $sibling)

A tagged union whose tag is a sibling key: one structure per value, and the chosen variant's keys are stored under the key.

Mix inThe timestamps structure's created and changed keys are merged into the resource's own keys, at its level. timestamps created changed the resource title created changed one level: stored flat, beside its own

Mix in

mixIn(Structure::class)

A structure whose members are merged into the owner's own keys: stored flat, refined in the owner's frame.

PortThe structure reads its port port_a from the container's key key_a; the port is not stored in the structure. the container key_a a structure port_a a port: read, not stored key_b reads: port_a => key_a

Port

reads($port, $type) and attach(..., reads:)

A value a structure reads from its container under a name of its own: a live sibling value, never stored or drawn by the structure.

CollectionA list at the key visibility, of any length, each item the child's keys. the resource visibility any number: the Count is the parent's item 0 child's keys item 1 child's keys item 2 child's keys

Collection

attachList($key, Child::class, min:, max:)

A list of child instances at a key: the list and its Count are the parent's, and each item is the child's.

Keys from the siteA provider lists the things the site has, and the map at the key entries gets one entry per thing. a provider lists the things the site has, at every build - entry_a - entry_b - entry_c the resource entries entry_a entry_b entry_c once added

Keys from the site

addEach() and attachEach()

One key per thing the site has, in a map at a key, listed by a provider at every build.

A resource or structure is made of others in six ways, and each keeps the keys in a different place. Nest for a thing of its own, mix in for shared members that are part of this thing, and read a port for a value the container holds. Use variants when a key chooses the keys, a collection when groups repeat, and keys from the site when the site, not the code, decides how many there are.

Read more Which way to compose, Children, Keys that come from the site. Decisions Variants, not slots, A port is a live sibling value, A mixin is merged flat, A list of child invocations, Keys that come from the site.

Part of Surface API; see the full explainer.