# `MishkaCmsCore.Runtime.PageBuilder.DesignToken`
[🔗](https://github.com/mishka-group/mishka_cms_core/blob/v0.0.1/lib/mishka_cms_core/runtime/page_builder/design_token.ex#L5)

The Studio's Design tokens tab, as a Gervaz table.

## A resource with no table behind it

A design token is not a row anywhere. It is a custom-property declaration inside a `Stylesheet`
row's CSS text, parsed out by `MishkaCmsCore.Runtime.PageBuilder.Tokens`. Gervaz needs an Ash
RESOURCE to build a table — it reads the attributes, the filters and the actions off one — but it
never needs a data layer, so this resource has none. Ash defaults that to
`Ash.DataLayer.Simple`, and the `on_load` hook hands it the parsed tokens with
`Ash.DataLayer.Simple.set_data/2`.

Everything downstream then works unchanged: Simple applies the filter, the sort, the limit and the
offset in memory, so the category chips and load-more are real Gervaz features rather than markup
that reimplements them.

## What it cannot do

Simple has no aggregate support, so nothing here may ask for a count — `type :numbered` or
`show_total true` would raise. Load-more does not count: it reads `page_size + 1` rows and infers
"there is more" from the extra one, which is why it is the pagination this table uses.

The site whose stylesheets are read arrives as `path_params[:site_id]`, the same channel the draft
picker scopes itself through.

See `MishkaCmsCoreWeb.Templates.StudioTokens`, which owns the whole of this table's markup.

# `t`

```elixir
@type t() :: %MishkaCmsCore.Runtime.PageBuilder.DesignToken{
  __lateral_join_source__: term(),
  __meta__: term(),
  __metadata__: term(),
  __order__: term(),
  aggregates: term(),
  calculations: term(),
  category: term(),
  custom: term(),
  glyph: term(),
  id: term(),
  key: term(),
  label: term(),
  usage: term(),
  value: term()
}
```

# `default_short_name`

# `input`

```elixir
@spec input(values :: map() | Keyword.t()) :: map() | no_return()
```

Validates that the keys in the provided input are valid for at least one action on the resource.

Raises a KeyError error at compile time if not. This exists because generally a struct should only ever
be created by Ash as a result of a successful action. You should not be creating records manually in code,
e.g `%MyResource{value: 1, value: 2}`. Generally that is fine, but often with embedded resources it is nice
to be able to validate the keys that are being provided, e.g

```elixir
Resource
|> Ash.Changeset.for_create(:create, %{embedded: EmbeddedResource.input(foo: 1, bar: 2)})
|> Ash.create()
```

# `input`

```elixir
@spec input(values :: map() | Keyword.t(), action :: atom()) :: map() | no_return()
```

Same as `input/1`, except restricts the keys to values accepted by the action provided.

# `primary_key_matches?`

# `rows`

```elixir
@spec rows(map()) :: [struct()]
```

The tokens of one site, in the shape this resource declares.

A site with no theme stylesheet has no tokens, and an empty Studio is not what that should look
like — so it falls back to the sample set, exactly as the hand-rolled list did before this became
a table.

---

*Consult [api-reference.md](api-reference.md) for complete listing*