Closed lifeart closed 8 months ago
for js-framework benchmark
"select row case"
I'm trying to debug vm stack,
given:
class
<MyComponent class={{if (eq a b) "c" "d"}} @foo={{bar}} />
MyComponent template has ...attributes binding for <tr> tag.
...attributes
<tr>
current behavour:
invalidation of a/b for closure condition inside loop, invalidates component tag itself
jump if not modified not working, and all components checks rerunning.
jump if not modified
because we have to execute patch-element (...attributes closure from class={...})
patch-element
expected behavour:
...attribute "class" modification should not invalidate component tag (should we have one more stack for it?)
idea is - do not invalidate component tag if only binded attribute changed (outside)
ref: https://github.com/glimmerjs/glimmer-vm/pull/132
corner case may be in case of we have to merge attribute modification logic, but it's statically analyzed.
example:
// parent: <Child class="foo" />
// child: <tr ...attributes class="things to merge">...</tr>
or move "patch-element" logic before "jump-if-not-modified", without counting it's tag
Closing as implemented for https://github.com/lifeart/glimmer-next
for js-framework benchmark
"select row case"
I'm trying to debug vm stack,
given:
class
bindingMyComponent template has
...attributes
binding for<tr>
tag.current behavour:
invalidation of a/b for closure condition inside loop, invalidates component tag itself
jump if not modified
not working, and all components checks rerunning.because we have to execute
patch-element
(...attributes closure from class={...})expected behavour:
...attribute "class" modification should not invalidate component tag (should we have one more stack for it?)
idea is - do not invalidate component tag if only binded attribute changed (outside)
ref: https://github.com/glimmerjs/glimmer-vm/pull/132
corner case may be in case of we have to merge attribute modification logic, but it's statically analyzed.
example: