Aim to replace the abstraction "Context" from OWL 1 with the new primitives
"atom" and "useState":
- notification is done only after a batch of modifications.
- observers are notified at most once for a batch.
- an observer of type component is notified (and rerendered)
only if it does not have an ancestor that has to be notified for the
same batch of operations (anywhere in the web of references!).
- notification of components is done on all levels "simultaneously".
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Géry Debongnie <ged@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
The CSS tag is useful to define a css stylesheet in the javascript file:
```js
class MyComponent extends Component {
static template = xml`
<div class="my-component">some template</div>
`;
static style = css`
.my-component {
color: red;
}
`;
}
```
The `css` tag registers internally the css information. Then, whenever the first instance of the component is created, will add a <style> tag to the document <head>.
Original commit in Owl v1: 953778dc5
fine grained reactivity:
existing key in source changes --> only observer having read the key are notified
add/delete key in source changes --> all source observers are notified
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Géry Debongnie <ged@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Synthetic handler is a sort of event delegation that allows placing
only one listener on the document to improve performance. It is an opt-in option.
Native listener places the listener on the node itself.
We reintroduce the possibility to mount the app in first position in
a target. The option "self" has been dropped since it is now possible
for a component to have several top level nodes.
We re-add the possibility to validate props when dev mode is active.
No change in the API right Now. The dev mode is activated via the
configure method of App class.
Previously, when a component node had been created and destroyed, and
the corresponding component was then recreated, the destroyed node was
reused. This commit fixes that
This commit reintroduces some tests for the t-set directive and make
them pass. For that, it was necessary to adapt the qweb compiler in
order to get the following behaviors:
A t-set can affect parent contexts (up to the first parent tagged as
boundary) when the key changed is found in one of the parent contexts.
Some context are marked as boundaries in such a way that
- rendering contexts (e.g. components) cannot be modified via a t-set.
- a t-set in a t-call body or in a called template can never change a
context above the t-call context.
Code prettification has been done.
Snapshots have been modified.
The point is to have visibility on the development of the owl2 features.
This commit reintroduces some tests keeping them skipped in order to fulfill that purpose.
There still are some missing tests though.
We add some test for the t-on directive.
For making them pass, it was necessary to change the code produced by
compileTForeach: the const declaration is not done by using generateId
and there was some conflict with the variable names produced in
captureExpression. Consequently, many snapshots had to be changed.
Code prettification has been done too.
This commit brings back the possibility to translate text nodes and
the attributes "label", "title", "placeholder", and "alt" in an app
configured with a suitable translation function.
It is also possible to deactivate translations under a node via
the directive t-translation="off".
For flexibility it is possible to define the list of translatable
attributes in the app.
When fixing the absence of capture for arrow functions passed as props,
we unintentionally introduced a breaking change: bare function calls in
the arrow functions used to be called with the rendering context as
their this value and this was no longer the case.
This commit fixes that by intentionally not capturing the value of
functions that are called withing the arrow function.
Currently in some cases, adding an attachment via lognote creates a traceback.
Error : shouldPatch is true while `vnode` is not defined, so `patch()` failed
This is a hotfix correcting this problem by calling `patch()` only if `shouldPatch` is true **and** the `vnode` is set.
opw-2645203
In some very rare cases (such as the use of the t-foreach directive),
Owl did leak the values in the render context in the global context.
This was due to the fact that the compiled template looked like this:
let _3 = _4 = _5;
instead of
let _3 = _5;
let _4 = _5;
It is worse having a dev mode in a production environment than the
opposite. The purpose of the warning was to avoid that situation.
However, in prod mode, it is not really necessary to log the config key.
closes#915
This is a tricky commit. The key point is that the Fiber.complete
method, which commits a rendering to the DOM works like this: it
traverses the component tree, patch the corresponding DOM for each
component, calls the mounted/destroy hooks, and reset the currentfiber
of components to null, all synchronously.
However, this means that it is possible for components to initiate a
rendering (which create a new currentFiber) before the currentFiber is
reset to null, so the internal state of owl is corrupted. This can
occurs in a crash, as in the test that accompanies this commit.
To fix this, we take care of resetting the currentFiber first, while we
walk the component tree. Then, the internal state is always consistent
(i.e. a currentFiber to null means that there is no pending rendering)
closes#904
If we want to upgrade Typescript to version >4 (in this repo or another using
owl), we also need jest >25. Jest <26 do not support Typescript >4.
However, jest >26 has a few breaking changes that completely breaks owl in
tests.
This commit updates jest to the current latest version (27) and adapts the
code accordingly.
A few words on what changed
---------------------------
1. the default test environment is no longer `jsdom`. It is now manually
configured to restore the previous env.
2. the jsdom version has been upgraded. This brings a few breaking changes,
detailed later.
3. there's a bug in jsdom >16.4. Manually created `<t/>` (by qweb compilation)
are recognized as "T" and not "t". Qweb thinks it's a component (since the
first letter is capitalized), but it's not a component: boom, everything
breaks.
A fix has been proposed here jsdom/jsdom#3240. But it's not likely to land
in jest in the short term (jest would need to update its dependency to the
next major jsdom version). This commit works around the problem for now by
creating `<t/>` slighty differently such that they are in an XML document
from the start (and not HTML document).
4. the xml parser implementation changed to increase the strictness and
correctness of XML parsing, according to specifications. A few tests needed
to be adapted.
https://github.com/jsdom/jsdom/commit/c96decf837ece54bdc550dfb7dca7e5d6c97bc2d
5. jest matcher `toHaveProperty` now check inherited properties. This breaks a
few tests. Since the breaking assertions didn't bring a lot of value from a
behavior point of view (it was more "white box" technical tests), they are
removed in this commit
https://github.com/facebook/jest/commit/1256f76a5a83034b51c7524142b60b099f69a7ab
6. jsdom now implements the behavior of links (`<a/>`). One test was `click`ing
on such a link, with the right click. Jsdom now tries to navigate to the
pointed URl...but crashes because navigation is not implemented :(
It turns out the test is probably not a valid/realistic scenario. On every
tested browser (chrome - chromium - brave - edge -firefox - safari), a
right click with the mouse triggers a `contextmenu` event and no `click`
event.
https://github.com/jsdom/jsdom/commit/cc95abc576f596ff7f3eaf8245f376e1f21aa485
Previously, if two attributes in t-att-class shared some classes, their
presence would be determined by the last attribute declared, instead of
being present if any attribute containing it evaluates to true. This
commit fixes that.
The previous changes in the combine method (used to copy all the
variables defined in the current scope for use in a slot) had the effect
of squashing the prototype chain: instead of `Component -> Obj1 ->
Obj2 -> Obj3`, the combined scope had: `Component -> Obj1'`.
This has an unfortunate interaction with the way t-call is implemented,
which uses the fact that we are in a subscope to add a own
__access_mode__. It depends specifially on the prototype chain, and that
the parent scope may have a different value for that property. But with
the way combine was implemented, we lost all that subtlety since
everything is squashed.
In this commit, we reimplement that function in a way to make sure we
keep the prototype chain structure
Before this commit, Owl inline expressions with a list with multiple
elements such as [a,b,c] was transformed into
[scope['a'], b: scope['b'], scope['c']]
instead of
[scope['a'], scope['b'], scope['c']]
This is due to a previous commit adding support for short object
descriptions such as {a,b}.
To fix this means that we have to keep track of the current group type
for the expression, which is done by using a stack.
In some situations (a slot inside a slot), the combine method was
wrongly copying all properties of the scope into the context, which
caused the event handling system to wrongly use a subobject as component
(since it detects the fact that __owl__ is a own property_).
Consequently, we could have very subtle issue with some properties being
shadowed by a sub object.
There is a possibility that the transitionend event of an element/component
with t-transition directive won't trigger. Though this situation is
difficult to assert, it was observe in odoo runbot for the pos ui.
When the transitionend event is not fired, the callback that removes
the element from the dom won't be called, resulting to a corrupted view.
An example of which is the following:
```html
<div t-if="show" t-transition="fade">Hello</div>
```
If `show` is set to false by some ui action and by any chance the
transitionend event is not fired (perhaps because the transition didn't
actually start or because of completely unknown reason), the div element
will remain in the view -- and this is not desirable.
This commit patches this situation such that if after 50ms that the
transitionend event is supposed to be fired but the event isn't fired, we
force the callback using a setTimeout. This guarantees the call of the
callback that is suppose to remove the element from the view.
Géry Debongnie