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
Snabbdom supports svg, but it adds the namespace at the creation of the
virtual node. However, owl works slightly differently: it adds children
after creating the parent virtual node.
So, we need to actually call the addNS method after the children nodes
have been created.
As a bonus, this is slightly faster than snabbdom: we only check at
template compilation time once if a node is a svg.
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.
This is a tricky bug. The problem is that a ConnectedComponent can
trigger a rendering before it is aware that there is a state change in
the store, and just before the store update event comes in.
What we do in this commit is to update the storeProps whenever a
rendering is scheduled. However, we need to keep the rendering
information as a promise to give it in some case to the __checkUpdate
method (see the note in the render method)
closes#268
It was not correct, the url was changed multiple times and back
navigation was broken.
Also, note that there are no tests because the history api is not
available in jsdom.
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.
Before this commit, hashchanges were not taken into account by the
router, if used in history mode.
Also, it's stupid, but i ran prettier on the codebase
Géry Debongnie