Selected <select> option is ghosted from previous DOM state.

[vdzk]

The state of a <select> element seems to be handled incorrectly when it's replaced by another <select> element under certain conditions. I reproduced it in Chrome and Firefox so it's probably an issue with lighterhtml. Here is the test case code + codepen.

const { render, html } = lighterhtml

const Option = ({label, value, selected}) => html`
  <option value=${value} selected="${selected}" >
    ${label}
  </option>
`

const Select = (options, onChange) => html`
  <select onchange=${(e) => onChange(e.target.value)}>
    ${options.map(Option)}
  </select>
`

let showNumbers = true
let activeNumber = '2'
let activeLetter = 'a'

const numbers = ['1', '2', '3', '4']
const letters = ['a', 'b']

const toggle = () => {
  showNumbers = !showNumbers
  update()
}
const setNumber = (num) => {
  activeNumber = num
  update()
}
const setLetter = (letter) => {
  activeLetter = letter
  update()
}

const getOptions = (arr, active) => arr.map(item => ({
  label: item,
  value: item,
  selected: item === active,
}))

const SelectNumber = () => {
  const options = getOptions(numbers, activeNumber)
  return Select(options, setNumber)
}
const SelectLetter = () => {
  const options = getOptions(letters, activeLetter)
  // return Select(options, setLetter)
  return html`<span>${Select(options, setLetter)}</span>`
}

const App = () => html`
  <button onclick=${toggle}>
    toggle
  </button>
  ${(showNumbers) ? SelectNumber() : SelectLetter()}
`

const update = () => render(document.body, App)

update()

Steps to reproduce: click on "toggle" button three times.
Expected result: selected options show 2 -> a -> 2 -> a . I see this result if I uncomment the first return statement in SelectLetter.
Observed results: selected options show 2 -> a -> 3 -> b .
It took me a while to zero in on the issue 😌

[WebReflection]

I hope it's not related to this bug WebReflection/hyperHTML#148

[WebReflection]

The following works just fine:

const { render, html } = lighterhtml

const Option = ({label, value, selected}) => html`
  <option value=${value} selected="${selected}" >
    ${label}
  </option>
`

const Select = (options, onChange) => html`
  <select onchange=${(e) => onChange(e.target.value)}>
    ${options.map(Option)}
  </select>
`

let showNumbers = true
let activeNumber = '2'
let activeLetter = 'a'

const numbers = ['1', '2', '3', '4']
const letters = ['a', 'b']

const toggle = () => {
  showNumbers = !showNumbers
  update()
}
const setNumber = (num) => {
  activeNumber = num
  update()
}
const setLetter = (letter) => {
  activeLetter = letter
  update()
}

const getOptions = (arr, active) => arr.map(item => ({
  label: item,
  value: item,
  selected: item === active,
}))

const SelectNumber = () => {
  const options = getOptions(numbers, activeNumber)
  return Select(options, setNumber)
}
const SelectLetter = () => {
  const options = getOptions(letters, activeLetter)
  return Select(options, setLetter)
}

const App = () => html`
  <button onclick=${toggle}>
    toggle
  </button>
  ${(showNumbers) ? SelectNumber() : SelectLetter()}
`

const update = () => render(document.body, App)

update()

I don't know why you have two different selects there, but basically lighterhtml doesn't like asymmetric conditional layout (same way React with hooks doesn't) so just don't create it for the time being, as I'm not sure this will be fixed any time soon.

Probably worth a note in the README though.

[WebReflection]

To clarify further ...

The state of a <select> element seems to be handled incorrectly when it's replaced by another <select> element under certain conditions.

this statement is not precise, 'cause you replace a select with a span that contains a select, which is probably not even valid HTML, but even if it was a <div>, you are replacing a tree with a completely different structure, and I'm actually surprise it doesn't just throw errors.

[vdzk]

The following works just fine:

Yes, I included \\return Select(options, setLetter) in my original example to show exactly that.

I don't know why you have two different selects there

My application has two different selects. Obviously it has more than just that but for the sake of narrowing down the issue I spent a long time reducing it bit by bit to the minimal example in my original post.

basically lighterhtml doesn't like asymmetric conditional layout (same way React with hooks doesn't) so just don't create it for the time being, as I'm not sure this will be fixed any time soon.

This is very surprising to me. I have a top nav panel and a main container below which has different layout conditional on where I navigate in the app. I didn't have problems with this structure in React (didn't try hooks). Are you saying that in lighterhtml is not suitable for this and I should switch to something else to avoid sporadic DOM update behavior?

this statement is not precise, 'cause you replace a select with a span that contains a select, which is probably not even valid HTML, but even if it was a <div>,

Sorry for being too vague. I thought that my description and a functioning code example was enough to show the issue. Yes, I changed <span> to <div> and the issue remained.

you are replacing a tree with a completely different structure, and I'm actually surprise it doesn't just throw errors.

What errors did you expect? Are you saying that in lighterhtml holes in template literals contents must always have the same type and structure?

To be clear, I'm thankful for you creating this project and I managed to mitigate this particular issue in my application. However now it seems that lighterhtml is not suited for some types of dynamic layouts (still not sure which and why) and more issue like this are to be expected.

[WebReflection]

Are you saying that in lighterhtml is not suitable for this and I should switch to something else to avoid sporadic DOM update behavior?

No. I am saying asymmetric layouts like this one are unnecessary. You can have the same select with different attributes or options in there, and everything will be just fine.

Are you saying that in lighterhtml holes in template literals contents must always have the same type and structure?

No, I am saying I don't see a use case for your example.

However now it seems that lighterhtml is not suited for some types of dynamic layouts (still not sure which and why) and more issue like this are to be expected.

I never had any issue with lighterhtml in general, but I also have 200 porjects in github, so I need to prioritize my bug-fixing time.

This looks like a browser-rabbit-hole (there are bugs related to selects already as mentioned before) I am not sure it's worth my time.

If you can help finding the issue and file a MR, it'd be surely faster, as solution.

It'd also help checking if the same issue happens with hyperHTML, 'cause they share the same core.

If not, it means I can re-open this and dig harder at some point, but not as soon as you'd like too.

Thanks for your understanding.

[WebReflection]

so, reopened in case I'll find some time to dig or in case you'd like to solve this too 👋

[WebReflection]

I've found the issue https://codepen.io/WebReflection/pen/qzKRgB?editors=0010

Given the following html

<select>
  <option>a</option>
  <option>b</option>
  <option>c</option>
  <option>d</option>
<select>

and the following JS

const select = document.querySelector('select');
const option = select.querySelectorAll('option');
option[1].selected = true;

you can see the selected option is the second one, letter b.

however, if you remove the the first two options from the select

select.removeChild(option[0]);
select.removeChild(option[1]);

you can see that option[2].selected is now true, even if not explicitly set.

That's it, whenever the select is re-populated, the last selected option gets automatically promoted to the one selected, so you'll incrementally see always the next one as the selected one.

setTimeout(
  () => {
    const fr = document.createDocumentFragment();
    let i = 0;
    while (i < option.length)
      fr.appendChild(option[i++]);
    select.appendChild(fr);
  },
  2000
);

This is somehow a twist of the bug WebReflection/hyperHTML#148, but this will likely affect all browsers.

This is also a very specific select with options issue, and I'm not sure how to properly address such issue without penalizing 99.9% of other non select with option related cases.

I'll take some time to think about this, but at least now I know WTF is going on, and it has nothing to do with lighterhtml, but it reflects through it.

I need to double check if hyperHTML is affected too, because if it is, it's a bit of a mess (although these two libraries are quite different, so that wired content might not be affected).

[WebReflection]

actually .. what a mess ... I need to reopen this

[WebReflection]

OK: now it's fixed https://codepen.io/WebReflection/pen/ZdRJKd?editors=0010 👋