Closed jurekbarth closed 4 years ago
I don't know if we should classify this as a bug or as just missing documentation.
In your example if you don't remove the span
on L32, then the input is not re-rendered.
Suggested replacement:
// here, i'm just replacing the span element with a div element, not removing it the entire element.
${counter % 2 === 0 ? html`<span>${counter}</span>` : html`<div>${counter}</div>`}
This is most likely due to the "diff" algorithm not being able to track the "input" element since a previous element "disappeared". This does seem a reasonable explanation because if you move your L34 to before L32, then the input does not get re-rendered. Additionally, if you don't do it in a partial, everything works as expected.
My suggestion is add some documentation suggesting that developers do not alter the HTML structure of the initial this.html
call and use CSS to manipulate it instead (if re-renders are an issue).
What do you think?
Steps to reproduce the behavior: A little bit hard to explain, that why i also made an example: https://codepen.io/jurekbarth/pen/gOOyWZM
If you fill out every form element and then click the counter. The last form element gets reset because it's not wired to the element. Lighterhtml mentions that in the documentation:
Expected behavior The form element keeps it's value.
In order to do so you could use
html.for()
as mentioned in the lighterhtml documentation, e.g.I think it's expected behavior, but it should be mentioned somehow in the docs and the upgrade guide. As far as i know it's not mentioned anywhere.
This only applies to form elements as far as i can think of. It might affect css animations though. So i might need a little more investigation work to get all cases together.