Select tag value

Is there any way to set the value of a select tag from the tag its self rather than setting selected on the child option tags?

I would like to be able to write:

el("select#kittens", {selected: "two"},
   [el("option", {value: "one"}, "one"),
    el("option", {value: "two"}, "two"),
    el("option", {value: "three"}, "three")])

Rather than:

el("select#kittens",
   [el("option", {value: "one"}, "one"),
    el("option", {value: "two", selected: true}, "two"),
    el("option", {value: "three"}, "three")])

If this is not possible currently is it a feature that you would consider adding to the domvm?

[leeoniya]

Eh, I doubt most people are coming to domvm from vanilla HTML/JS/DOM.

most likely come from jQuery since there are many more of them than the rest combined. this is part of the reason that the lib focuses on distributing a pre-built single file, staying small, tooling-free and as easy to get started with as jQuery.

i expect domvm’s more sophisticated audience to be able to discern JSX-isms (className="..."), React-isms (synthetic camelcase events) and Mithril-isms (withAttr, etc.) from vanilla HTML/JS/DOM. i’m not particularly keen on imitating features from those by adding non-standard special cases unless the value is sufficiently high and does not introduce a perf overhead or add a bunch of extra internal machinery.

to implement this in domvm, i’d need to add handling in at least the hot preProcBody() and either mutate the attrs object of the parent to ensure it doesnt actually set a selected or value attrs on the select or add a bypass check to all the hot attrs loops. if the API was something closer to the more-explicit ivi, eg h.select().attrs().children(), then it would be easier to do without affecting perf lib-wide.

the value-added here isn’t worth it IMO vs having a very simple helper.

[leeoniya]

i was hoping this would suffice, and it mostly does, except for initial mount 😠: https://jsfiddle.net/740b3ja3/

i agree with @lawrence-dol that it’d be most logical with value. however, it would be a feature that’d be difficult to discover because HTML Doesn’t Work Like That ™️.

given that <option>s cannot contain complex elements or even attributes other than value/selected, i’m tempted not to add anything and just have people use a helper function. it’s not all that scary and doesnt impose a penalty across the whole lib:

function selected(value, optEls) {
  optEls.forEach(el => {
    if (el.attrs.value === value)
      el.attrs.selected = true;
  });
  return optEls;
}

el("select#kittens", selected("two", [
  el("option", {value: "one"}, "one"),
  el("option", {value: "two"}, "two"),
  el("option", {value: "three"}, "three")
]))

autofocus is another one that could use special handling…and to mimic html would only need to work on initial root mount and not any view mount afterwards, though the latter may be more useful.