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
It now takes two arguments: parent (optional, only for non-root
components) and props (optional). In the case of the root component,
the env is taken from the config (config.defaultEnv). If it doesn't
exists, the default env is created on the fly.
Closes#306
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
This commit also changes the behaviour of willPatch and patched: they no
longer transfer data from one to the other, because it can be done
cleanly by hooks and a closure.
closes#307
If we want to generate dynamically svg components, it is useful to be
able to define components with a <g> tag as root, and then getting the
correct namespace.
closes#302
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
Before this commit, QWeb crashed when it had to deal with a t-call with
multiple sub nodes on the same line, and one text node:
<t t-call="SomeTemplate">
<span>hey</span> <span>hey</span>
</t>
This was because we need to compile the content to be able to extract
all possible t-set t-value statements. But doing so means that we had a
multiple root templates, which caused a crash in this case.
Solving this issue is simple: the sub template is compiled with the flag
allowMultipleRoots set to true.
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.
Aaron Bohy