solidjs / solid / 36761005805

76%

main: 89%

push

github

web: binding-slot fills run once, bound as client JSX binds (#3713)

A binding slot's fill ran inside `createMemo(() => fill(args))`, so a
top-level read in its body re-ran the fill and disposed whatever it had
created. Now a binding fill runs as a component body does: once per
occurrence, untracked and labelled, under the occurrence's owner. Value
positions keep one render effect per occurrence. Handlers and refs bind
once through `assign`, so they delegate, take tuples and wrap
interactions as client JSX does. Template-slot fills are untracked on
every render path. On the server, an array at a handler position is a
dev finding (`tuple`) instead of being flattened.

Public API changes:
- An eager plain-object binding fill stops updating; a top-level read is
  a one-time read (dev: STRICT_READ_UNTRACKED naming the fill).
- State created in a fill lives as long as the occurrence.
- Binding handlers are delegated for the events client JSX delegates.
- Handlers and refs are read once, when an element binds.
- `AttributeSlot` -> `BindingSlot<Args, Bindings>` (no alias), with a
  constrained return; `SlotOutput` and `SlotError` are new exports of
  `@solidjs/web/frames`.
- Diagnostic code `ATTRIBUTE_SLOT_POSITION` -> `BINDING_SLOT_POSITION`
  (also in `@solidjs/signals`' `DiagnosticCode`).
- Server-side handler tuples are a dev finding (reason `tuple`).
- Template-slot fills warn STRICT_READ_UNTRACKED on top-level reads.
- The `fill-shape` finding names async values; a handler marker with
  several keys binds the last.

Size: no frozen cap raised. Merged with next @ 3c1f809ff, the pages
measure 45,934 / 50,125 B against next's 46,036 / 50,166 B.

649 of 925 branches covered (70.16%)

Branch coverage included in aggregate %.

962 of 1195 relevant lines covered (80.5%)

27.68 hits per line