# entityList behaviour

*Open when you are placing a record list / workspace over an entity, or a view tab on one is not showing what you configured.*

One element draws the whole workspace: breadcrumb, toolbar (search, filters, Create), the view-tab strip, and the active data view over `dataSource.entity`'s records. Its children are toolbar slots the runtime injects, not layout you author — `slots` is runtime-managed, never write it.

**`namedViews` is yours, though.** It is the tab strip's *builder-mode* source — an array of seeds on `EntityListElementSchema` that the builder mutates directly, with no backend call, and the form authoring guide lists it among `entityList`'s authorable props beside `views` / `defaultView` / `availableViewTypes`. A seed is `{ title, icon, type: 'system' }` plus its own filter; `title` is `LocalizedText` and `icon` takes the **IconValue object** (`{ name, color?, size?, bgColor?, … }`), never a bare glyph string. The platform's own defaults are *All* (no filter) and *Created by me* (`author.id = $currentUser.id`). At **runtime** the same strip is backed by per-user backend `Layout[]` records instead — those are the reader's and must not be authored, which is what makes the two halves easy to confuse.

**Its columns are not in the form.** `entityList` is the one element that refuses the builder's
column drill-in (`supportsColumnDrillIn()` is `true` on every other runtime): a list's visible
fields, widths, pinning, sort, grouping and filters live in an entity-scoped `Layout` record, saved
through *Save view*, and its per-column options are edited in **Entity Builder → Views → Table**.
Authoring `settings.columns` here configures nothing. (A standalone `table` element is the
opposite: it owns its columns in its own schema — see `references/tables.md`.)

`availableViewTypes` is the only switch that makes a view type *reachable*. The runtime takes it when non-empty, else the enabled `views[]` presets' types, else `table` + `list`. A `cards` or `dashboard` block whose type is missing from it is dead config — authored, validated, never rendered.

`defaultView` is a `views[].id`, **not** a view type: `defaultView: 'cards'` matches no preset, the active view stays null, and the list silently opens as a plain table.

A preset is `{ id, type, enabled, config }`, and `config` is the **only** home of a kanban / calendar / gantt view's own configuration — grouping, date fields, dependencies. Offering `kanban` with no preset ships a "grouping is not configured" placeholder beside a working table; the gate catches that case and only that one.

Scoping trap: in `dataSource.filter`, a leaf with `valueSource: 'variable'` or `'urlParam'` that resolves empty is not compared against nothing — the runtime **deletes the leaf from the query**, so a list meant to show one folder's records shows all of them. Give it a `fallbackValue`; the lint for that fires only on kanban `columnFilter`, never here.