O componente mais usado que falta a um tema de documentação: um parâmetro de
API, com mais explicação do que aquela que cabe numa linha de tabela.

## Utilização

::preview
:::field{name="showRepo" type="boolean" default="false"}
Força um segmento de repositório mesmo com um só repositório.
:::

#code
```mdc
::field{name="showRepo" type="boolean" default="false"}
Força um segmento de repositório mesmo com um só repositório.
::
```
::

## API

### Props

| Prop       | Tipo      | Por omissão | Notas                                                |
| :--------- | :-------- | :---------- | :--------------------------------------------------- |
| `name`     | `string`  | —           | O nome do parâmetro, em monoespaçado                 |
| `type`     | `string`  | —           | Desenhado ao lado dele, em monoespaçado              |
| `default`  | `string`  | —           | Alinhado à direita, como `= value`                   |
| `required` | `boolean` | `false`     | Desenha um distintivo em vez de um valor por omissão |

### Slots

| Slot      | O que leva dentro        |
| :-------- | :----------------------- |
| `default` | A descrição, em Markdown |

## Notas

Uma lista de definições seria a escolha semântica e é a errada aqui: o nome, o
tipo, o valor por omissão e se é obrigatório são quatro coisas diferentes, e
`<dt>` dá-lhes um só slot para todas.

Uma tabela continua a ser a melhor escolha para uma lista longa de campos de uma
linha — ver [Fontes](/reference/sources), onde oito campos são para comparar de
relance em vez de lidos um a um.