We don't see any usecase for it, it makes the code more complex,
and there were still potential unresolved concurrency issues with
it.
Part of task #295
Before this rev., default values weren't taken into account when
validating props whenever a component was updated. Moreover, there
was no test attesting that props were validated at update.
it is not useful to do it in the component directive, especially since
it is done in the constructor, and the default props are not applied.
closes#379
With this commit, we can now do this:
const SUBTEMPLATE = xml`<span><t t-esc="state.n"/></span>`
class Parent extends Widget {
static template = xml`<div><t t-call="${SUBTEMPLATE}"/></div>`
state = {n: 42};
}
Big change! This commit introduces an xml function tag to easily define
inline templates.
This is a pretty big change toward single file owl components
Part of #284
Of course, the templateId computation is kind of tricky. Here, an issue
occurred because the templateId did not take the componentId into
account when we were in a loop, but with no keyed parent.
This meant that multiple sub components shared the same templateId,
confusing the vdom algorithm.
This is a difficult part of owl: we need to be able to reconcile the
vdom generated (this is done with our virtual dom algorithm), but also
to be able to reconcile the proper components.
The issue here is that when we are in a list, with a t-key attribute on all
list nodes, and those list nodes contains sub component, then the
component system used the index of the list, and did not take into
account the key from the parent. The fix is to keep track of the
current key in the context, and uses that as a part of the templateId.
Aaron Bohy