[serjek]

Controlled <select value="..."> templates currently fail to compile because React's value prop is absent from the HTML select attributes supplied by tink_domspec.

Add -D coconut_react_dom_select_value to opt into a select value prop accepting a string or an array of strings for multiple selection. This allows selection to follow application state, including programmatic resets. Default behavior stays unchanged.

The define and README make the portability limitation explicit: coconut.html and coconut.vdom use selected on individual options and cannot consume these templates unchanged.

Validation: ordinary selects compile without the define; controlled single and multiple selects compile with it; controlled values are rejected without it. The consuming frontend's browser integration checks previously covered controlled select resets and reactive inputs.

ARIA definitions remain in tink_domspec, covered separately by tink_domspec PR #43.

[back2dos]

I'm a bit split about this. Setting aside my distaste for React so often deviating from the DOM APIs, the bigger issue is that it invites code that is incompatible with:

• coconut.vdom: probably irrelevant, but easy to fix
• coconut.html: relevant for full stack with proper hydration, unless one is willing to commit to React on the server side as well ... but a bit harder to fix

Will see if Claude can solve the latter. Otherwise I would put this under a define, so that users opt into the stumbling block.

[serjek]

Yes good point! I see if we can avoid this change at all.

[back2dos]

Works fine now. It was just a bit finnicky for coconut.html. The v1 branch goes through strings and tries to flatten as much as possible at compile time, so select and option needed an exemption, but it turned out quite claudable.

[serjek]

Thanks!