Expand the use of the bind syntax

[thejackshelton]

RFC: Generalized bind: Syntax for HTML Attributes

Problem Statement

Qwik's bind: syntax implementation is currently half baked and inconsistent. Supporting bind:checked and bind:value for seemingly arbitrary reasons, lacking a systematic approach for consumers to know when they can use the bind syntax on a jsx element.

This is not something new, both Svelte and Angular have very similar approaches. Now just because these frameworks support the feature doesn't mean we should do it, but since we've already adopted the API, and it's been public for quite some time now in production apps, I think it would be valuable to make it more powerful.

Example:

// Qwik
const message = useSignal('hello');
<input bind:value={message} />

// Svelte 5 with Runes
let message = $state('hello');
<input bind:value={message} />

I would also strongly suggest reading through how it works with runes (Svelte's version of signals) here:
https://svelte.dev/docs/svelte/bind

Current State:

Currently supported (arbitrarily)

<input bind:value={signal} />
<input type="checkbox" bind:checked={signal} />

Not supported but equally valid

<dialog open={isOpen} />           // Why not bind:open?
<details open={isExpanded} />      // Why not bind:open?
<input disabled={isDisabled} />    // Why not bind:disabled?
<video muted={isMuted} />         // Why not bind:muted?
<audio volume={vol} />            // Why not bind:volume?
<meter value={val} />             // Why not bind:value?

Proposed Solution / Feature

Proposed Solution

Allow the bind: prefix for any boolean or value attribute on HTML elements where two-way binding makes sense.

Extend the bind attribute to props, where developers can add their own custom binds.

API Design:

<input bind:value={valueSignal} />                 // Already exists
<input type="checkbox" bind:checked={checkedSig}>  // Already exists
<input type="range" bind:value={rangeSig}>         // Need to add
<input type="file" bind:files={filesSig}>          // Need to add
<input type="radio" bind:group={groupSig}>         // Need to add
<textarea bind:value={textSig}>                    // Need to add
<select bind:value={selectSig}>                    // Need to add

// Media Elements
<video
  bind:currentTime={timeSignal}
  bind:duration={durationSignal}
  bind:paused={pausedSignal}
  bind:volume={volumeSignal}
>

// UI Elements
<details bind:open={openSignal}>
<dialog bind:open={openSignal}>

Benefits

1. Consistency: Any attribute that can be bound, can use bind: syntax
2. Predictability: Developers can expect bind: to work for any appropriate attribute
3. Completeness: Full coverage of HTML attributes that represent state
4. Type Safety: TypeScript can properly type all bindable attributes

Implementation Details

1. Optimizer recognizes bind: prefix for any or most valid HTML attributes
2. Runtime handles two-way synchronization based on element and attribute type
3. TypeScript types ensure correct attribute types

Migration Strategy

This is an additive change. Existing bind:value and bind:checked continue to work.

Open Questions

1. Should we support SVG attributes?
2. Could custom components support it? E.g <MySelect bind:value />
3. Performance implications of supporting all attributes?

Next Steps

1. Implement generalized bind: support
2. Add TypeScript types for all bindable attributes
3. Update documentation
4. Add examples to playground

Links / References

No response

[wmertens]

So most of these would be read-only bindings right? Nice!

Currently the bind is implemented inside the optimizer but once QwikDev/qwik#7269 lands we can make QwikDev/qwik#6989 work and then we can easily implement all the logic we like for DOM element prop handling.

I don't think Qwik Components should have special handling for it because you don't know what the change event is for a given prop, plus it would break passing down binds to DOM elements.