[📖] explain uncontrolled vs controlled components about qwik

[maiieul]

shouldn't we follow the same pattern as Form and provide an Input which has more qwik helpers but if you wanted you still can use the native version

My understanding is that the Formcomponent is to enable passing actions when submitting the form. I'm not sure there's a need for that on Input.. But I think we should create another feature request issue if you see a real need for it @PatrickJS.

[maiieul]

Just for more context, in Vue it would be something like that:

//uncontrolled -> behaves like vanilla html
<input type="checkbox" checked={true} />

//controlled (one way data-binding)
const acceptConditions = useRef(false);
<input
  :checked="acceptConditions"
  @change="event => acceptConditions = event.target.checked"
">

//controlled (two way data-binding = syntactic sugar to achieve above behavior)
const acceptConditions = useRef(false);
<input type="checkbox" v-model="acceptConditions">

[PatrickJS]

shouldn't we follow the same pattern as Form and provide an Input which has more qwik helpers but if you wanted you still can use the native version

[thejackshelton]

shouldn't we follow the same pattern as Form and provide an Input which has more qwik helpers but if you wanted you still can use the native version

To be honest, even I am confused about the <Form /> component. This issue is about making the distinction between initial and reactive values in the docs much clearer for consumers.

Qwik is modeled after normal html, except for the bind syntax.

There is confusion when migrating no matter which ecosystem you look at, because other JSX frameworks decided they were going to do something different. (cough React)

See:
https://discord.com/channels/990511757091033108/1218888360525955122/1241445135686828102

for more context

[PatrickJS]

Form is confusing too I made some effort to fix it but it needs to be slightly reworked