# selection.StringFilterFields

- **Module:** selection
- **Package:** @libtmux/libtmux
- **Language:** TypeScript
- **Kind:** typealias
- **Source:** https://github.com/libtmux/libtmux-ts/blob/2cb93308200da38a26b59876618116850f110607/packages/libtmux/src/selection.ts#L51
- **Page:** https://libtmux.org/reference/ts/selection-stringfilterfields/

A field's criteria accept its decoded shape as well as the text tmux sends: `where({ active: true })` and `where({ active: "1" })` are the same query, and serialize identically. A `null` criterion matches any wire value that the field decoder treats as absent or invalid, rather than one particular wire spelling.

The text side exists because the wire does. `encodeFormatValue` lowers every
criterion to tmux's text before a query is serialized, and
`WhereDocumentV1` types both what a caller writes and what
`decodeWhereDocument` gives back — so a type that refused text would be
lying about the documents this library's own encoder produces. That is the
difference from an ORM, whose query AST never round-trips through a type the
caller also authors.

`Raw` is therefore not a taste. `"0" | "1"` is the exact wire domain for a
flag, while an integer uses `${bigint}` intersected with a decimal prefix.
That rules out fractions, exponents, radix prefixes, leading zeroes, `-0`,
`NaN`, and prose. TypeScript cannot bound an integer's magnitude, so the
query validator also requires safe range at runtime. `format_values.test.ts`
holds the layers in step.

The substring operations stay `string` deliberately: `contains` asks about
the characters tmux sent, and a numeric field's text has characters like any
other.
