[DOC] reorganize and update documentation to owl 2

2025-10-06 19:59:41 +07:00 · 2022-01-13 10:26:14 +01:00
parent 41ad5db2e3
commit 82c7c24438
33 changed files with 1396 additions and 2488 deletions
@@ -16,8 +16,10 @@ framework, written in Typescript, taking the best ideas from React and Vue in a
 simple and consistent way. Owl's main features are:
 - a declarative component system,
- a reactivity system based on hooks,
+- a fine grained reactivity system similar to Vue,
- concurrent mode by default,
+- hooks
 - fragments
 - asynchronous rendering
 Owl components are defined with ES6 classes and xml templates, uses an
 underlying virtual DOM, integrates beautifully with hooks, and the rendering is
@@ -38,28 +40,26 @@ const { Component, useState, mount, xml } = owl;
 class Counter extends Component {
  static template = xml`
-    <button t-on-click="() => state.value++">
+    <button t-on-click="() => state.value = state.value + props.increment">
      Click Me! [<t t-esc="state.value"/>]
    </button>`;
  state = useState({ value: 0 });
 }
-class App extends Component {
+class Root extends Component {
  static template = xml`
    <div>
    <span>Hello Owl</span>
-      <Counter />
+    <Counter increment="2"/>`;
    </div>`;
  static components = { Counter };
 }
-mount(App, document.body);
+mount(Root, document.body);
 ```
 Note that the counter component is made reactive with the [`useState` hook](doc/reference/hooks.md#usestate).
-Also, all examples here uses the [`xml` helper](doc/reference/tags.md#xml-tag) to define inline templates.
+Also, all examples here uses the [`xml` helper](doc/reference/templates.md#inline-templates) to define inline templates.
 But this is not mandatory, many applications will load templates separately.
 More interesting examples can be found on the
@@ -74,47 +74,42 @@ Are you new to Owl? This is the place to start!
 - [Tutorial: create a TodoList application](doc/learning/tutorial_todoapp.md)
 - [How to start an Owl project](doc/learning/quick_start.md)
 - [How to test Components](doc/learning/how_to_test.md)
 - [How to write Single File Components](doc/learning/how_to_write_sfc.md)
 ### Reference
-You will find here a complete reference of every feature, class or object
+- [Overview](doc/readme.md)
-provided by Owl.
+- [App](doc/reference/app.md)
 - [Animations](doc/reference/animations.md)
 - [Browser](doc/reference/browser.md)
 - [Component](doc/reference/component.md)
- [Content](doc/reference/content.md)
+- [Component Lifecycle](doc/reference/component.md#lifecycle)
 - [Concurrency Model](doc/reference/concurrency_model.md)
- [Configuration](doc/reference/config.md)
+- [Dynamic sub components](doc/reference/component.md#dynamic-sub-components)
 - [Context](doc/reference/context.md)
 - [Environment](doc/reference/environment.md)
 - [Event Bus](doc/reference/event_bus.md)
 - [Event Handling](doc/reference/event_handling.md)
 - [Error Handling](doc/reference/error_handling.md)
 - [Event Handling](doc/reference/event_handling.md)
 - [Form Input Bindings](doc/reference/input_bindings.md)
 - [Fragments](doc/reference/templates.md#fragments)
 - [Hooks](doc/reference/hooks.md)
- [Mounting a component](doc/reference/mounting.md)
+- [Loading Templates](doc/reference/app.md#loading-templates)
- [Miscellaneous Components](doc/reference/misc.md)
+- [Mounting a component](doc/reference/app.md#mount-helper)
- [Observer](doc/reference/observer.md)
+- [Portal](doc/reference/portal.md)
 - [Props](doc/reference/props.md)
- [Props Validation](doc/reference/props_validation.md)
+- [Props Validation](doc/reference/props.md#props-validation)
- [QWeb Templating Language](doc/reference/qweb_templating_language.md)
+- [Reactivity](doc/reference/reactivity.md)
- [QWeb Engine](doc/reference/qweb_engine.md)
+- [Rendering SVG](doc/reference/templates.md#rendering-svg)
 - [Refs](doc/reference/refs.md)
 - [Slots](doc/reference/slots.md)
- [Tags](doc/reference/tags.md)
+- [Sub components](doc/reference/component.md#sub-components)
 - [Sub templates](doc/reference/templates.md#sub-templates)
 - [Templates (Qweb)](doc/reference/templates.md)
 - [Translations](doc/reference/translations.md)
 - [Utils](doc/reference/utils.md)
 ### Other Topics
-This section provides miscellaneous document that explains some topics
+- [Notes On Owl Architecture](doc/miscellaneous/architecture.md)
 which cannot be considered either a tutorial, or reference documentation.
 - [Owl architecture: the Virtual DOM](doc/miscellaneous/vdom.md)
 - [Owl architecture: the rendering pipeline](doc/miscellaneous/rendering.md)
 - [Comparison with React/Vue](doc/miscellaneous/comparison.md)
- [Why did Odoo built Owl?](doc/miscellaneous/why_owl.md)
+- [Why did Odoo build Owl?](doc/miscellaneous/why_owl.md)
-
+- [Changelog (from owl 1.x to 2.x)](CHANGELOG.md)
 ## Installing Owl
@@ -1,52 +0,0 @@
 # 🦉 How to write Single File Components 🦉
 It is very useful to group code by feature instead of by type of file. It makes
 it easier to scale application to larger size.
 To do so, Owl has two small helpers that make it easy to define a
 template or a stylesheet inside a javascript (or typescript) file: the
 [`xml`](../reference/tags.md#xml-tag) and [`css`](../reference/tags.md#css-tag)
 helper.
 This means that the template, the style and the javascript code can be defined in
 the same file. For example:
 ```js
 const { Component } = owl;
 const { xml, css } = owl.tags;
 // -----------------------------------------------------------------------------
 // TEMPLATE
 // -----------------------------------------------------------------------------
 const TEMPLATE = xml/* xml */ `
 	<div class="main">
 		<Sidebar/>
 		<Content />
 	</div>`;
 // -----------------------------------------------------------------------------
 // STYLE
 // -----------------------------------------------------------------------------
 const STYLE = css/* css */ `
  .main {
    display: grid;
    grid-template-columns: 200px auto;
  }
 `;
 // -----------------------------------------------------------------------------
 // CODE
 // -----------------------------------------------------------------------------
 class Main extends Component {
  static template = TEMPLATE;
  static style = STYLE;
  static components = { Sidebar, Content };
  // rest of component...
 }
 ```
 Note that the above example has an inline xml comment, just after the `xml` call.
 This is useful for some editor plugins, such as the VS Code addon
 `Comment tagged template`, which, if installed, add syntax highlighting to the
 content of the template string.
@@ -116,7 +116,7 @@ class App extends Component {}
 App.template = xml`<div>todo app</div>`;
 ```
-Note 3: writing inline templates with the [`xml` helper](../reference/tags.md#xml-tag)
+Note 3: writing inline templates with the [`xml` helper](../reference/templates.md#inline-templates)
 is nice, but there is no syntax highlighting, and this makes it very easy to
 have malformed xml. Some editors support syntax highlighting for this situation.
 For example, VS Code has an addon `Comment tagged template`, which, if installed,
@@ -173,14 +173,14 @@ class Root extends Component {
 }
 ```
-The template contains a [`t-foreach`](../reference/qweb_templating_language.md#loops) loop to iterate
+The template contains a [`t-foreach`](../reference/templates.md#loops) loop to iterate
 through the tasks. It can find the `tasks` list from the component, since the
 component is the rendering context. Note that we use the `id` of each task as a
 `t-key`, which is very common. There are two css classes: `task-list` and `task`,
 that we will use in the next section.
 Finally, notice the use of the `t-att-checked` attribute:
-prefixing an attribute by [`t-att`](../reference/qweb_templating_language.md#dynamic-attributes) makes
+prefixing an attribute by [`t-att`](../reference/templates.md#dynamic-attributes) makes
 it dynamic. Owl will evaluate the expression and set it as the value of the
 attribute.
@@ -277,10 +277,10 @@ A lot of stuff happened here:
 - the `Task` component has a `props` key: this is only useful for validation
  purpose. It says that each `Task` should be given exactly one prop, named
  `task`. If this is not the case, Owl will throw an
-  [error](../reference/props_validation.md). This is extremely
+  [error](../reference/props.md#props-validation). This is extremely
  useful when refactoring components
 - finally, to activate the props validation, we need to set Owl's
-  [mode](../reference/config.md#mode) to `dev`. This is done in the last argument
+  [mode](../reference/app.md#configuration) to `dev`. This is done in the last argument
  of the `mount` function. Note that this should be removed when an app is used in a real
  production environment, since `dev` mode is slightly slower, due to extra
  checks and validations.
@@ -0,0 +1,68 @@
 # 🦉 Notes On Owl Architecture 🦉
 We explain here how Owl is designed
 Warning: these notes are technical by nature, and intended for people working
 on Owl (or interested in understanding its design).
 ## Overview
 Roughly speaking, Owl has 5 main parts:
 - a virtual dom system (in `src/blockdom`)
 - a component system (in `src/component`)
 - a template compiler (located in the `src/compiler` folder)
 - a small runtime code to tie them together (in `src/app`)
 - a reactivity system (in `src/reactivity.ts`)
 There are some other files, but the core of Owl can be understood with these
 five main parts.
 The virtual dom is an optimized virtual dom based on blocks, which supports
 multi blocks (for fragments). Everything that owl renders is internally
 represented by a virtual node. The job of the virtual dom is to efficiently
 represent the current state of the application, and to build an actual DOM
 representation when needed, or update the DOM whenever it is needed.
 - some other helpers/smaller scale stuff
  A rendering occurs in two phases:
 - virtual rendering: this generates the virtual dom in memory, asynchronously
 - patch: applies a virtual tree to the screen (synchronously)
 There are several classes involved in a rendering:
 - components
 - a scheduler
 - fibers: small objects containing some metadata, associated with a rendering of
  a specific component
 Components are organized in a dynamic component tree, visible in the user
 interface. Whenever a rendering is initiated in a component `C`:
 - a fiber is created on `C` with the rendering props information
 - the virtual rendering phase starts on C (will asynchronously render all the
  child components)
 - the fiber is added to the scheduler, which will poll continuously, every
  animation frame, if the fiber is done
 - once it is done, the scheduler will call the task callback, which will apply
  the patch (if it was not cancelled in the meantime).
 # 🦉 VDom 🦉
 Owl is a declarative component system: we declare the structure of the component
 tree, and Owl will translate that to a list of imperative operations. This
 translation is done by a virtual dom. This is the low level layer of Owl, most
 developer will not need to call directly the virtual dom functions.
 The main idea behind a virtual dom is to keep a in-memory representation of the
 DOM (called a virtual node), and whenever some change is needed, to regenerate
 a new representation, compute the difference between the old and the new, then
 apply the changes.
 `vdom` exports two functions:
 - `h`: create a new virtual node
 - `patch`: compare two virtual nodes, and apply the difference.
 Note: Owl's virtual dom is a fork of [snabbdom](https://github.com/snabbdom/snabbdom).
@@ -78,7 +78,7 @@ additional tools, we made a lot of effort to make the most of the web platform.
 For example, Owl uses the standard `xml` parser that comes with every browser.
 Because of that, Owl did not have to write its own template parser. Another
-example is the [`xml`](../reference/tags.md#xml-tag) tag helper function, which makes use of
+example is the [`xml`](../reference/templates.md#inline-templates) tag helper function, which makes use of
 native template literals to allow in a natural way to write `xml` templates
 directly in the javascript code. This can be easily integrated with editor
 plugins to have autocompletion inside the template.
@@ -126,7 +126,7 @@ structured than a template language. Note that the tooling is quite impressive:
 there is a syntax highlighter for jsx here on github!
 By comparison, here is the equivalent Owl component, written with the
-[`xml`](../reference/tags.md#xml-tag) tag helper:
+[`xml`](../reference/templates.md#inline-templates) tag helper:
 ```js
 class Clock extends Component {
@@ -1,32 +0,0 @@
 # 🦉 Rendering Pipeline 🦉
 We explain here how Owl is designed, from the perspective of its rendering
 pipeline.
 Warning: these notes are technical by nature, and intended for people working
 on Owl (or interested in understanding its design).
 ## Overview
 A rendering occurs in two phases:
 - virtual rendering: this generates the virtual dom in memory, asynchronously
 - patch: applies a virtual tree to the screen (synchronously)
 There are several classes involved in a rendering:
 - components
 - a scheduler
 - fibers: small objects containing some metadata, associated with a rendering of
  a specific component
 Components are organized in a dynamic component tree, visible in the user
 interface. Whenever a rendering is initiated in a component `C`:
 - a fiber is created on `C` with the rendering props information
 - the virtual rendering phase starts on C (will asynchronously render all the
  child components)
 - the fiber is added to the scheduler, which will poll continuously, every
  animation frame, if the fiber is done
 - once it is done, the scheduler will call the task callback, which will apply
  the patch (if it was not cancelled in the meantime).
@@ -1,18 +0,0 @@
 # 🦉 VDom 🦉
 Owl is a declarative component system: we declare the structure of the component
 tree, and Owl will translate that to a list of imperative operations. This
 translation is done by a virtual dom. This is the low level layer of Owl, most
 developer will not need to call directly the virtual dom functions.
 The main idea behind a virtual dom is to keep a in-memory representation of the
 DOM (called a virtual node), and whenever some change is needed, to regenerate
 a new representation, compute the difference between the old and the new, then
 apply the changes.
 `vdom` exports two functions:
 - `h`: create a new virtual node
 - `patch`: compare two virtual nodes, and apply the difference.
 Note: Owl's virtual dom is a fork of [snabbdom](https://github.com/snabbdom/snabbdom).
@@ -0,0 +1,42 @@
 # 🦉 Owl overview 🦉
 Here is a list of everything exported by the Owl library:
 Main entities:
 - [`App`](reference/app.md): represent an Owl application (mainly a root component,a set of templates, and a config)
 - [`Component`](reference/component.md): the main class to define a concrete Owl component
 - [`mount`](reference/app.md#mount-helper): main entry point for most application: mount a component to a target
 - [`useState`](reference/reactivity.md#usestate): create a reactive object (hook, linked to a specific component)
 - [`reactive`](reference/reactivity.md#reactive): create a reactive object (not linked to any component)
 - [`xml`](reference/templates.md#inline-templates): helper to define an inline template
 Lifecycle hooks:
 - [`onWillStart`](reference/component.md#willstart): hook to define asynchronous code that should be executed before component is rendered
 - [`onMounted`](reference/component.md#mounted): hook to define code that should be executed when component is mounted
 - [`onWillPatch`](reference/component.md#willpatch): hook to define code that should be executed before component is patched
 - [`onWillUpdateProps`](reference/component.md#willupdateprops): hook to define code that should be executed before component is updated
 - [`onPatched`](reference/component.md#patched): hook to define code that should be executed when component is patched
 - [`onWillRender`](reference/component.md#willrender): hook to define code that should be executed before component is rendered
 - [`onRendered`](reference/component.md#rendered): hook to define code that should be executed after component is rendered
 - [`onWillUnmount`](reference/component.md#willunmount): hook to define code that should be executed before component is unmounted
 - [`onWillDestroy`](reference/component.md#willdestroy): hook to define code that should be executed before component is destroyed
 - [`onError`](reference/component.md#onerror): hook to define a Owl error handler
 Other hooks:
 - [`useComponent`](reference/hooks.md#usecomponent): return a reference to the current component (useful to create derived hooks)
 - [`useEffect`](reference/hooks.md#useeffect): define an effect with its dependencies
 - [`useEnv`](reference/hooks.md#useenv): return a reference to the current env
 - [`useExternalListener`](reference/hooks.md#useexternallistener): add a listener outside of a component DOM
 - [`useRef`](reference/hooks.md#useref): get an object representing a reference (`t-ref`)
 - [`useSubEnv`](reference/hooks.md#usesubenv): extend the current env with additional information for child components
 Utility/helpers:
 - [`EventBus`](reference/utils.md#eventbus): a simple event bus
 - [`loadFile`](reference/utils.md#loadfile): an helper to load a file from the server
 - [`markup`](reference/templates.md#outputting-data): utility function to define strings that represent html (should not be escaped)
 - [`status`](reference/component.md#status-helper): utility function to get the status of a component (new, mounted or destroyed)
 - [`whenReady`](reference/utils.md#whenready): utility function to execute code when DOM is ready
@@ -1,127 +0,0 @@
 # 🦉 Animations 🦉
 Animation is a complex topic. There are many different use cases, and many
 solutions and technologies. Owl only supports some basic use cases.
 ## Simple CSS effects
 Sometimes, using pure CSS is enough. For these use cases, Owl is not really
 necessary: it just needs to render a DOM element with a specific class. For
 example:
 ```xml
 <a class="btn flash" t-on-click="doSomething">Click</a>
 ```
 with the following CSS:
 ```css
 btn {
  background-color: gray;
 }
 .flash {
  transition: background 0.5s;
 }
 .flash:active {
  background-color: #41454a;
  transition: background 0s;
 }
 ```
 will produce a nice flash effect whenever the user clicks (or activates with the
 keyboard) the button.
 ## CSS Transitions
 A more complex situation occurs when we want to transition an element in or out
 of the page. For example, we may want a fade-in and fade-out effect.
 The `t-transition` directive is here to help us. It works on html elements and
 on components, by adding and removing some css classes.
 To perform useful transition effects, whenever an element appears or disappears,
 it is necessary to add/remove some css style or class at some precise moment in
 the lifetime of a node. Since this is not easy to do by hand, Owl `t-transition`
 directive is there to help.
 Whenever a node has a `t-transition` directive, with a `name` value, the following
 sequence of events will happen:
 At node insertion:
 - the css classes `name-enter` and `name-enter-active` will be added directly
  when the node is inserted into the DOM.
 - on the next animation frame: the css class `name-enter` will be removed and the
  class `name-enter-to` will be added (so they can be used to trigger css
  transition effects).
 - at the end of the transition, `name-enter-to` and `name-enter-active` will be removed.
 At node destruction:
 - the css classes `name-leave` and `name-leave-active` will be added before the
  node is removed to the DOM.
 - on the next animation frame: the css class `name-leave` will be removed and the
  class `name-leave-to` will be added (so they can be used to trigger css
  transition effects).
 - at the end of the transition, `name-leave-to` and `name-leave-active` will be removed.
 For example, a simple fade in/out effect can be done with this:
 ```xml
 <div>
    <div t-if="state.flag" class="square" t-transition="fade">Hello</div>
 </div>
 ```
 ```css
 .fade-enter-active,
 .fade-leave-active {
  transition: opacity 0.5s;
 }
 .fade-enter,
 .fade-leave-to {
  opacity: 0;
 }
 ```
 The `t-transition` directive can be applied on a node element or on a component.
 Notes:
 Owl does not support more than one transition on a single node, so the
 `t-transition` expression must be a single value (i.e. no space allowed).
 ## SCSS Mixins
 If you use SCSS, you can use mixins to make generic animations. Here is an exemple with a fade in / fade out animation:
 ```scss
@mixin animation-fade($time, $name) {
  .#{$name}_fade-enter-active,
  .#{$name}_fade-active {
    transition: all $time;
  }
  .#{$name}_fade-enter {
    opacity: 0;
  }
  .#{$name}_fade-leave-to {
    opacity: 0;
  }
 }
 ```
 Usage:
 ```scss
@include animation-fade(0.5s, "o_notification");
 ```
 You can now have in your template:
 ```xml
 <SomeTag  t-transition="o_notification_fade"/>
 ```
@@ -0,0 +1,107 @@
 # 🦉 App 🦉
 ## Content
 - [Overview](#overview)
 - [Configuration](#configuration)
 - [`mount` helper](#mount-helper)
 - [Loading templates](#loading-templates)
 ## Overview
 Every Owl application has a root element, a set of templates, an environment and
 possibly a few other settings. The `App` class is a simple class that represents
 all of these elements. Here is an example:
 ```js
 const {Component, App } = owl;
 class MyComponent extends Component { ... }
 const app = new App(MyComponent, { props: {...}, templates: "..."});
 app.mount(document.body);
 ```
 The basic workflow is: create an `App` instance configured with the root
 component, the templates, and possibly other settings. Then, we mount that
 instance somewhere in the DOM.
 ## Configuration
 - **`constructor(Root[, config])`**: first argument should be a component class (not
  an instance), and the optional second argument is a configuration object.
  The `config` object is an object with some of the following keys:
  - **`env (object)`**: if given, this will be the shared `env` given to each component
  - **`props (object)`**: the props given to the root component
  - **`dev (boolean, default=false)`**: if `true`, the application is rendered in `dev`
    mode, which activates some additional checks (in particular, the props validation
    code is only performed in dev mode)
  - **`translatableAttributes (string[])`**: a list of additional attributes that should
    be translated (see [translations](translations.md))
  - **`translateFn (function)`**: a function that will be called by owl to translate
    templates (see [translations](translations.md))
  - **`templates (string | xml document)`**: all the templates that will be used by
    the components created by the application.
 - **`mount(target, options)`**: first argument is an html element, and the optional
  second argument is an object with mounting options (see below). Mount the app
  to a target in the DOM. Note that this is an asynchronous operation: the `mount`
  method returns a promise that resolves to the component instance whenever it
  is complete.
  The `option` object is an object with the following keys:
  - **`position (string)`**: either `first-child` or `last-child`. This option determines
    the position of the application in the target: either first or last child.
 - **`destroy()`**: destroys the application
 ## `mount` helper
 Note that there is a `mount` helper to do that in just a line:
 ```js
 const { mount, Component } = owl;
 class MyComponent extends Component {
    ...
 }
 mount(MyComponent, document.body, { props: {...}, templates: "..."});
 ```
 Here is the `mount` function signature:
 **`mount(Component, target, config)`** with the following arguments:
 - **`Component`**: a component class (Root component of the app)
 - **`target`**: an html element, where the component will be mounted as last child
 - **`config (optional)`**: a config object (the same as the App config object)
 Most of the time, the `mount` helper is more convenient, but whenever one needs
 a reference to the actual Owl App, then using the `App` class directly is
 possible.
 ## Loading templates
 Most applications will need to load templates whenever they start. Here is
 what it could look like in practice:
 ```js
 // in the main js file:
 const { loadFile, mount } = owl;
 // async, so we can use async/await
 (async function setup() {
  const templates = await loadFile(`/some/endpoint/that/return/templates`);
  const env = {
    _t: someTranslateFn,
    templates,
    // possibly other stuff
  };
  mount(Root, document.body, { env });
 })();
 ```
@@ -1,33 +0,0 @@
 # 🦉 Browser 🦉
 ## Content
 - [Overview](#overview)
 - [Browser Content](#browser-content)
 ## Overview
 The browser object contains some browser native APIs, such as `setTimeout`, that
 are used by Owl and its utility functions. They are exposed with the intent of
 making them mockable if necessary.
 ```js
 owl.browser.setTimeout === window.setTimeout; // return true
 ```
 For now, this object contains some functions that are not used by Owl. They
 will eventually be removed in Owl 2.0.
 ## Browser Content
 More specifically, the `browser` object contains the following methods and objects:
 - `setTimeout`
 - `clearTimeout`
 - `setInterval`
 - `clearInterval`
 - `requestAnimationFrame`
 - `random`
 - `Date`
 - `fetch`
 - `localStorage`
@@ -11,7 +11,7 @@
 Owl was designed from the very beginning with asynchronous components. This comes
 from the `willStart` and the `willUpdateProps` lifecycle hooks. With these
-methods, it is possible to build complex highly concurrent applications.
+asynchronous hooks, it is possible to build complex highly concurrent applications.
 Owl concurrent mode has several benefits: it makes it possible to delay the
 rendering until some asynchronous operation is complete, it makes it possible
@@ -35,7 +35,8 @@ two phases: _virtual rendering_ and _patching_.
 ### Virtual rendering
-This phase represent the process of rendering a template, in memory, which create a virtual representation of the desired component html). The output of this phase is a
+This phase represent the process of rendering a template, in memory, which creates
 a virtual representation of the desired component html). The output of this phase is a
 virtual DOM.
 It is asynchronous: each subcomponents needs to either be created (so, `willStart`
@@ -94,7 +95,7 @@ component (with some code like `app.mount(document.body)`).
 5. The method `mounted` is called recursively on all components in the following
   order: `E`, `D`, `C`, `B`, `A`.
-**Scenario 2: rerendering a component**. Now, let's assume that the user clicked on some
+**Scenario 2: updating a component**. Now, let's assume that the user clicked on some
 button in `C`, and this results in a state update, which is supposed to:
 - update `D`,
@@ -136,8 +137,7 @@ Here is what Owl will do:
 6. `mounted` hook is called on `F`, `patched` hooks are called on `D`, `C`
 Tags are very small helpers to make it easy to write inline templates. There is
-only one currently available tag: `xml`, but we plan to add other tags later,
+only one currently available tag: `xml`.
 such as a `css` tag, which will be used to write [single file components](../learning/how_to_write_sfc.md).
 ### Asynchronous Rendering
@@ -160,22 +160,4 @@ Here are a few tips on how to work with asynchronous components:
 1. Minimize the use of asynchronous components!
 2. Lazy loading external libraries is a good use case for async rendering. This
   is mostly fine, because we can assume that it will only takes a fraction of a
-   second, and only once (see [`owl.utils.loadJS`](utils.md#loadjs))
+   second, and only once.
 3. For all the other cases, the [`AsyncRoot`](misc.md#asyncroot) component is there to help you. When
   this component is met, a new rendering
   sub tree is created, such that the rendering of that component (and its
   children) is not tied to the rendering of the rest of the interface. It can
   be used on an asynchronous component, to prevent it from delaying the
   rendering of the whole interface, or on a synchronous one, such that its
   rendering isn't delayed by other (asynchronous) components. Note that this
   directive has no effect on the first rendering, but only on subsequent ones
   (triggered by state or props changes).
   ```xml
   <div t-name="ParentComponent">
     <SyncChild />
     <AsyncRoot>
        <AsyncChild/>
     </AsyncRoot>
   </div>
   ```
@@ -1,44 +0,0 @@
 # 🦉 Config 🦉
 The Owl framework is designed to work in many situations. However, it is
 sometimes necessary to customize some behaviour. This is done by using the
 global `config` object. It provides two settings:
 - [`mode`](#mode) (default value: `prod`),
 - [`enableTransitions`](#enabletransitions) (default value: `true`).
 ## Mode
 By default, Owl is in _production_ mode, this means that it will try to do its
 job fast, and skip some expensive operations. However, it is sometimes necessary
 to have better information on what is going on, this is the purpose
 of the `dev` mode.
 Owl has a mode flag, in `owl.config.mode`. Its default value is `prod`, but
 it can be set to `dev`:
 ```js
 owl.config.mode = "dev";
 ```
 Note that templates compiled with the `prod` settings will not be recompiled.
 So, changing this setting is best done at startup.
 An important job done by the `dev` mode is to validate props for each component
 creation and update. Also, extra props will cause an error.
 ## `enableTransitions`
 Transitions are usually nice, but they can cause issues in some specific cases,
 such as automated tests. It is uncomfortable having to wait for a transition
 to end before moving to the next step.
 To solve this issue, Owl can be configured to ignore the `t-transition` directive.
 To do that, one only needs to set the `enableTransitions` flag to false:
 ```js
 owl.config.enableTransitions = false;
 ```
 Note that it suffers from the same drawback as the "dev" mode: all compiled
 templates, if any, will keep their current behaviours.
@@ -1,36 +0,0 @@
 # 🦉 Owl Content 🦉
 Here is a complete visual representation of everything exported by the `owl`
 global object.
 For example, `Component` is available at `owl.Component` and `EventBus` is
 exported as `owl.core.EventBus`.
 ```
 browser
 Component                               misc
 Context                                     AsyncRoot
 QWeb                                        Portal
 mount
 useState                                tags
 config                                      css
    mode                                    xml
 core                                    utils
    EventBus                                debounce
    Observer                                escape
 hooks                                       loadJS
    onWillStart                             loadFile
    onMounted                               shallowEqual
    onWillUpdateProps                       whenReady
    onWillPatch
    onPatched
    onWillUnmount
    useContext
    useState
    useRef
    useComponent
    useEnv
    useSubEnv
 ```
 Note that for convenience, the `useState` hook is also exported at the root of the `owl` object.
@@ -6,15 +6,15 @@
 - [Setting an Environment](#setting-an-environment)
 - [Using a sub environment](#using-a-sub-environment)
 - [Content of an Environment](#content-of-an-environment)
 - [Special keys](#special-keys)
 ## Overview
-An environment is an object which contains a [`QWeb` instance](qweb_engine.md). Whenever
+An environment is a shared object given to all components in a tree. It is not
-a root component is created, it is assigned an environment (see
+used by Owl itself, but it is useful for application developers to provide a
-[below](#setting-an-environment) for more info on this). This environment is
+simple communication channel between components (in addition to the props).
-then automatically given to each sub component (and accessible in the `this.env`
+
-property).
+The `env` given to the [`App`](app.md) is assigned to the `env` component
 property.
 ```
    Root
@@ -22,31 +22,14 @@ property).
   A    B
 ```
-This way, all components share the same `QWeb` instance. Owl internally requires
+Also, the `env` object is frozen when the application is started. This is done
-that the environment has a `qweb` key which maps to a
+to ensure a simpler mental model of what's happening in runtime. Note that it
-[`QWeb`](qweb_engine.md) instance. This is the QWeb instance that will be used to
+is only shallowly frozen, so sub objects can be modified.
 render each templates in this specific component tree. Note that if no `QWeb`
 instance is provided, Owl will simply generate it on the fly.
 The environment is mostly static. Each application is free to add anything to
 the environment, which is very useful, since this can be accessed by each sub
 component.
 ## Setting an environment
-An Owl application needs an [environment](environment.md) to be executed. The
+The correct way to customize an environment is to simply give it to the `App`,
-environment has an important key: the [QWeb](qweb_engine.md) instance, which will render
+whenever it is created.
 all templates.
 Whenever a root component `App` is mounted, Owl will setup a valid environment by
 following the next steps:
 - take the `env` object defined on `App.env` (if no `env` was explicitly setup,
  this will return the empty `env` object defined on `Component`)
 - if `env.qweb` is not set, then Owl will create a `QWeb` instance.
 The correct way to customize an environment is to simply set it up on the root
 component class, before the first component is created:
 ```js
 const env = {
@@ -56,20 +39,13 @@ const env = {
        ...
    },
 };
-mount(App, { target: document.body, env });
+
 new App(Root, { env }).mount(document.body);
 // or alternatively
 mount(App, document.body, { env });
 ```
 It is also possible to simply share an environment between all root components,
 by simply doing this:
 ```js
 Component.env = myEnv; // will be the default env for all components
 ```
 Note that this environment is the global owl environment for an application. The
 next section explains how to extend an environment for a specific sub component
 and its children.
 ## Using a sub environment
 It is sometimes useful to add one (or more) specific keys to the environment,
@@ -79,58 +55,22 @@ solution presented above will not work, since it sets the global environment.
 There is a hook for this situation: [`useSubEnv`](hooks.md#usesubenv).
 ```js
-class FormComponent extends Component {
+class SomeComponent extends Component {
-  constructor(parent, props) {
+  setup() {
-    super(parent, props);
+    useSubEnv({ myKey: someValue }); // myKey is now available for all child components
    useSubEnv({ myKey: someValue });
  }
 }
 ```
 ## Content of an Environment
-Some good use cases for additional keys in the environment are:
+The `env` object content is totally up to the application developer. However,
 some good use cases for additional keys in the environment are:
 - some configuration keys,
 - session information,
 - generic services (such as doing rpcs).
 - other utility functions that one want to inject, such as a translation function.
 Doing it this way means that components are easily testable: we can simply
 create a test environment with mock services.
 For example:
 ```js
 async function myEnv() {
  const templates = await loadTemplates();
  const qweb = new QWeb({ templates });
  const session = getSession();
  return {
    _t: myTranslateFunction,
    session: session,
    qweb: qweb,
    services: {
      localStorage: localStorage,
      rpc: rpc,
    },
    debug: false,
    inMobileMode: true,
  };
 }
 async function start() {
  const env = await myEnv();
  mount(App, { target: document.body, env });
 }
 ```
 ## Special Keys
 There are two special key/value added by Owl if not provided in the environment:
 the `QWeb` instance and a `browser` object:
 - `qweb` will be set to an empty `QWeb` instance. This is absolutely necessary
  for Owl to be able to render anything
 - `browser`: this is an object that contains some common access points to the
  browser methods with a side effect. See [browser](browser.md) for more information. Note that the browser object will be removed from the environment in Owl 2.0.
@@ -3,58 +3,28 @@
 ## Content
 - [Overview](#overview)
 - [Managing Errors](#managing-errors)
 - [Example](#example)
 - [Reference](#reference)
 ## Overview
 By default, whenever an error occurs in the rendering of an Owl application, we
 destroy the whole application. Otherwise, we cannot offer any guarantee on the
 state of the resulting component tree. It might be hopelessly corrupted, but
-without any user-visible state.
+without any user-visible feedback.
-Clearly, it sometimes is a little bit extreme to destroy the application. This
+Clearly, it is usually a little bit extreme to destroy the application. This
-is why we have a builtin mechanism to handle rendering errors (and errors coming
+is why we need a mechanism to handle rendering errors (and errors coming
-from lifecycle hooks): the `catchError` hook.
+from lifecycle hooks): the `onError` hook.
-## Example
+The main idea is that the `onError` hook register a function that will be called
 with the error. This function need to handle the situation, most of the time by
 updating some state and rerendering itself, so the application can return to a
 normal state.
-For example, here is how we could implement an `ErrorBoundary` component:
+## Managing Errors
-```xml
+Whenever the `onError` lifecycle hook is used, all errors coming from
 <div t-name="ErrorBoundary">
    <t t-if="state.error">
        Error handled
    </t>
    <t t-else="">
        <t t-slot="default" />
    </t>
 </div>
 ```
 ```js
 class ErrorBoundary extends Component {
  state = useState({ error: false });
  catchError() {
    this.state.error = true;
  }
 }
 ```
 Using the `ErrorBoundary` is then extremely simple:
 ```xml
 <ErrorBoundary><SomeOtherComponent/></ErrorBoundary>
 ```
 Note that we need to be careful here: the fallback UI should not throw any
 error, otherwise we risk going into an infinite loop (also, see the page on
 [slots](slots.md) for more information on the `t-slot` directive).
 ## Reference
 Whenever the `catchError` lifecycle hook is implemented, all errors coming from
 sub components rendering and/or lifecycle method calls will be caught and given
 to the `catchError` method. This allows us to properly handle the error, and to
 not break the application.
@@ -65,17 +35,41 @@ There are important things to know:
  Owl will destroy the full application. This is done on purpose, because Owl
  cannot guarantee that the state is not corrupted from this point on.
- errors coming from event handlers are NOT managed by `catchError` or any other
+- errors coming from event handlers are NOT managed by `onError` or any other
  owl mechanism. This is up to the application developer to properly recover
  from an error
-Also, it may be useful to know that whenever an error is caught, it is then
+- if an error handler is unable to properly handle an error, it can just rethrow
-broadcasted to the application by an event on the `qweb` instance. It may be
+  an error, and Owl will try looking for another error handler up the component
-useful, for example, to log the error somewhere.
+  tree.
 ## Example
 For example, here is how we could implement a generic component `ErrorBoundary`
 that render its content, and a fallback if an error happened.
 ```js
-env.qweb.on("error", null, function (error) {
+class ErrorBoundary extends Component {
-  // do something
+  static template = xml`
-  // react to the error
+    <t t-if="error" t-slot="fallback">An error occurred</t>
-});
+    <t t-else="" t-slot="content"`;
  setup() {
    this.state = useState({ error: false });
    onError(() => (this.state.error = true));
  }
 }
 ```
 Using the `ErrorBoundary` is then simple simple:
 ```xml
 <ErrorBoundary>
  <SomeOtherComponent/>
  <t t-set-slot="fallback">Some specific error message</t>
 </ErrorBoundary>
 ```
 Note that we need to be careful here: the fallback UI should not throw any
 error, otherwise we risk going into an infinite loop (also, see the page on
 [slots](slots.md) for more information on the `t-slot` directive).
@@ -3,22 +3,13 @@
 ## Content
 - [Event Handling](#event-handling)
 - [Business DOM Events](#business-dom-events)
 - [Inline Event Handlers](#inline-event-handlers)
 - [Modifiers](#modifiers)
 ## Event Handling
 In a component's template, it is useful to be able to register handlers on DOM
-elements to some specific events. This is what makes a template _alive_. There
+elements to some specific events. This is what makes a template _alive_. This
-are four different use cases.
+is done with the `t-on` directive. For example:
 1. Register an event handler on a DOM node (_pure_ DOM event)
 2. Register an event handler on a component (_pure_ DOM event)
 3. Register an event handler on a DOM node (_business_ DOM event)
 4. Register an event handler on a component (_business_ DOM event)
 A _pure_ DOM event is directly triggered by a user interaction (e.g. a `click`).
 ```xml
 <button t-on-click="someMethod">Do something</button>
@@ -31,93 +22,28 @@ button.addEventListener("click", component.someMethod.bind(component));
 ```
 The suffix (`click` in this example) is simply the name of the actual DOM
-event.
+event. The value of the `t-on` expression should be a valid javascript expression
-
+that evaluates to a function in the context of the current component. So, one
-## Business DOM Events
+can get a reference to the event, or pass some additional arguments. For example,
-
+all the following expressions are valid:
 A _business_ DOM event is triggered by a call to `trigger` on a component.
 ```xml
-<MyComponent t-on-menu-loaded="someMethod" />
+<button t-on-click="someMethod">Do something</button>
 <button t-on-click="() => this.increment(3)">Add 3</button>
 <button t-on-click="ev => this.doStuff(ev, 'value')">Do something</button>
 ```
-```js
+Notice the use of the `this` keyword in the lambda function: this is the
- class MyComponent {
+correct way to call a method on the component in a lambda function.
     someWhere() {
         const payload = ...;
         this.trigger('menu-loaded', payload);
     }
 }
 ```
-The call to `trigger` generates an `OwlEvent`, a subclass of [_CustomEvent_](https://developer.mozilla.org/docs/Web/Guide/Events/Creating_and_triggering_events)
+One could use the following expression:
 with an additional attribute `originalComponent` (the component that triggered
 the event). The generated event is of type `menu-loaded` and dispatches it on
 the component's DOM element (`this.el`). The event bubbles and is cancelable.
 The parent component listening to event `menu-loaded` will receive the payload
 in its `someMethod` handler (in the `detail` property of the event), whenever
 the event is triggered.
 ```js
 class ParentComponent {
     someMethod(ev) {
         const payload = ev.detail;
         ...
     }
 }
 ```
 By convention, we use KebabCase for the name of _business_ events.
 The `t-on` directive allows to prebind its arguments. For example,
 ```xml
-<button t-on-click="someMethod(expr)">Do something</button>
+<button t-on-click="() => increment(3)">Add 3</button>
 ```
-Here, `expr` is a valid Owl expression, so it could be `true` or some variable
+But then, the increment function may be unbound (unless the component binds it
-from the rendering context.
+in its setup function, for example).
 ### Type Hinting
 Note that if you work with Typescript, the `trigger` method is generic on the type of the payload.
 You can then describe the type of the event, so you will see typing errors...
 ```typescript
 this.trigger<MyCustomPayload>("my-custom-event", payload);
 ```
 ```typescript
 myCustomEventHandler(ev: OwlEvent<MyCustomPayload>) { ... }
 ```
 ## Inline Event Handlers
 One can also directly specify inline statements. For example,
 ```xml
 <button t-on-click="state.counter++">Increment counter</button>
 ```
 Here, `state` must be defined in the rendering context (typically the component)
 as it will be translated to:
 ```js
 button.addEventListener("click", () => {
  context.state.counter++;
 });
 ```
 Warning: inline expressions are evaluated in the context of the template. This
 means that they can access the component methods and properties. But if they set
 a key, the inline statement will actually not modify the component, but a key in
 a sub scope.
 ```xml
 <button t-on-click="value = 1">Set value to 1 (does not work!!!)</button>
 <button t-on-click="state.value = 1">Set state.value to 1 (work as expected)</button>
 ```
 ## Modifiers
@@ -3,24 +3,18 @@
 ## Content
 - [Overview](#overview)
- [Example: Mouse Position](#example-mouse-position)
+- [The Hook Rule](#the-hook-rule)
- [Example: Autofocus](#example-autofocus)
+- [Lifecycle hooks](#lifecycle-hooks)
- [Reference](#reference)
+- [Other hooks](#other-hooks)
  - [One Rule](#one-rule)
  - [`useState`](#usestate)
  - [`onMounted`](#onmounted)
  - [`onWillUnmount`](#onwillunmount)
  - [`onWillPatch`](#onwillpatch)
  - [`onPatched`](#onpatched)
  - [`onWillStart`](#onwillstart)
  - [`onWillUpdateProps`](#onwillupdateprops)
  - [`useContext`](#usecontext)
  - [`useRef`](#useref)
  - [`useSubEnv`](#usesubenv)
  - [`useExternalListener`](#useexternallistener)
  - [`useComponent`](#usecomponent)
  - [`useEnv`](#useenv)
-  - [Making customized hooks](#making-customized-hooks)
+  - [`useEffect`](#useeffect)
 - [Example: Mouse Position](#example-mouse-position)
 - [Example: Autofocus](#example-autofocus)
 ## Overview
@@ -39,96 +33,9 @@ Hooks work beautifully with Owl components: they solve the problems mentioned
 above, and in particular, they are the perfect way to make your component
 reactive.
-## Example: mouse position
+## The Hook Rule
-Here is the classical example of a non trivial hook to track the mouse position.
+There is only one rule: every hook for a component has to be called in the _setup_ method, or in class fields:
 ```js
 const { useState, onMounted, onWillUnmount } = owl.hooks;
 // We define here a custom behaviour: this hook tracks the state of the mouse
 // position
 function useMouse() {
  const position = useState({ x: 0, y: 0 });
  function update(e) {
    position.x = e.clientX;
    position.y = e.clientY;
  }
  onMounted(() => {
    window.addEventListener("mousemove", update);
  });
  onWillUnmount(() => {
    window.removeEventListener("mousemove", update);
  });
  return position;
 }
 // Main root component
 class App extends owl.Component {
  static template = xml`
    <div t-name="App">
      <div>Mouse: <t t-esc="mouse.x"/>, <t t-esc="mouse.y"/></div>
    </div>`;
  // this hooks is bound to the 'mouse' property.
  mouse = useMouse();
 }
 ```
 Note that we use the prefix `use` for hooks, just like in React. This is just
 a convention.
 ## Example: autofocus
 Hooks can be combined to create the desired effect. For example, the following
 hook combines the `useRef` hook with the `onPatched` and `onMounted` functions
 to create an easy way to focus an input whenever it appears in the DOM:
 ```js
 function useAutofocus(name) {
  let ref = useRef(name);
  let isInDom = false;
  function updateFocus() {
    if (!isInDom && ref.el) {
      isInDom = true;
      ref.el.focus();
    } else if (isInDom && !ref.el) {
      isInDom = false;
    }
  }
  onPatched(updateFocus);
  onMounted(updateFocus);
 }
 ```
 This hook takes the name of a valid `t-ref` directive, which should be present
 in the template. It then checks whenever the component is mounted or patched if
 the reference is not valid, and in this case, it will focus the node element.
 This hook can be used like this:
 ```js
 class SomeComponent extends Component {
  static template = xml`
    <div>
        <input />
        <input t-ref="myinput"/>
    </div>`;
  constructor(...args) {
    super(...args);
    useAutofocus("myinput");
  }
 }
 ```
 ## Reference
 ### One rule
 There is only one rule: every hook for a component has to be called in the
 constructor, in the _setup_ method, or in class fields:
 ```js
 // ok
@@ -136,14 +43,6 @@ class SomeComponent extends Component {
  state = useState({ value: 0 });
 }
 // also ok
 class SomeComponent extends Component {
  constructor(...args) {
    super(...args);
    this.state = useState({ value: 0 });
  }
 }
 // also ok
 class SomeComponent extends Component {
  setup() {
@@ -159,15 +58,24 @@ class SomeComponent extends Component {
 }
 ```
-As you can see, the `useState` hook does not need to be given a reference to
+## Lifecycle Hooks
 the component. This is possible because there is a way to get a reference to the
 current component: the `Component.current` static property is the reference to the
 component instance that is currently being created.
-Hooks need to be called in the constructor to ensure that this reference is
+All lifecycle hooks are documented in detail in their specific [section](component.md#lifecycle).
-properly set. This is also a good thing for performance reasons (Owl can use
+
-this to optimize its implementation), and for a clean architecture (this makes
+| Hook                                                  | Description                                                            |
-it easier for developers to understand what is really happening in a component).
+| ----------------------------------------------------- | ---------------------------------------------------------------------- |
 | **[onWillStart](component.md#willstart)**             | async, before first rendering                                          |
 | **[onWillRender](component.md#willrender)**           | just before component is rendered                                      |
 | **[onRendered](component.md#rendered)**               | just after component is rendered                                       |
 | **[onMounted](component.md#mounted)**                 | just after component is rendered and added to the DOM                  |
 | **[onWillUpdateProps](component.md#willupdateprops)** | async, before props update                                             |
 | **[onWillPatch](component.md#willpatch)**             | just before the DOM is patched                                         |
 | **[onPatched](component.md#patched)**                 | just after the DOM is patched                                          |
 | **[onWillUnmount](component.md#willunmount)**         | just before removing component from DOM                                |
 | **[onWillDestroy](component.md#willdestroy)**         | just before component is destroyed                                     |
 | **[onError](component.md#onerror)**                   | catch and handle errors (see [error handling page](error_handling.md)) |
 ## Other Hooks
 ### `useState`
@@ -178,9 +86,9 @@ The `useState` hook has to be given an object or an array, and will return
 an observed version of it (using a `Proxy`).
 ```javascript
-const { useState } = owl.hooks;
+const { useState, Component } = owl;
-class Counter extends owl.Component {
+class Counter extends Component {
  static template = xml`
    <button t-on-click="increment">
        Click Me! [<t t-esc="state.value"/>]
@@ -197,128 +105,38 @@ class Counter extends owl.Component {
 It is important to remember that `useState` only works with objects or arrays. It
 is necessary, since Owl needs to react to a change in state.
 ### `onMounted`
 `onMounted` is not a user hook, but is a building block designed to help make useful
 abstractions. `onMounted` registers a callback, which will be called when the component
 is mounted (see example on top of this page).
 ### `onWillUnmount`
 `onWillUnmount` is not a user hook, but is a building block designed to help make useful
 abstractions. `onWillUnmount` registers a callback, which will be called when the component
 is unmounted (see example on top of this page).
 ### `onWillPatch`
 `onWillPatch` is not a user hook, but is a building block designed to help make useful
 abstractions. `onWillPatch` registers a callback, which will be called just
 before the component patched.
 ### `onPatched`
 `onPatched` is not a user hook, but is a building block designed to help make useful
 abstractions. `onPatched` registers a callback, which will be called just
 after the component patched.
 ### `onWillStart`
 `onWillStart` is an asynchronous hook. This means that the function registered
 in the hook will be run just before the component is first rendered and can return a
 promise, to express the fact that it is an asynchronous operation.
 Note that if there are more than one `onWillStart` registered callback, then they
 will all be run in parallel.
 It can be used to load some initial data. For example, the following hook will
 automatically load some data from the server, and return an object that will
 be ready whenever the component is rendered:
 ```js
 function useLoader() {
  const component = Component.current;
  const record = useState({});
  onWillStart(async () => {
    const recordId = component.props.id;
    Object.assign(record, await fetchSomeRecord(recordId));
  });
  return record;
 }
 ```
 Note that this example does not update the record value whenever props are
 updated. For that situation, we need to use the `onWillUpdateProps` hook.
 ### `onWillUpdateProps`
 Just like `onWillStart`, `onWillUpdateProps` is an asynchronous hook. It is
 designed to be run whenever the component props are updated. This could be
 useful to perform some asynchronous task such as fetching updated data.
 ```js
 function useLoader() {
  const component = Component.current;
  const record = useState({});
  async function updateRecord(id) {
    Object.assign(record, await fetchSomeRecord(id));
  }
  onWillStart(() => updateRecord(component.props.id));
  onWillUpdateProps((nextProps) => updateRecord(nextProps.id));
  return record;
 }
 ```
 Note that if there are more than one `onWillUpdateProps` registered callback,
 then they will all be run in parallel.
 ### `useContext`
 See [`useContext`](context.md#usecontext) for reference documentation.
 ### `useRef`
 The `useRef` hook is useful when we need a way to interact with some inside part
-of a component, rendered by Owl. It can work either on a DOM node, or on a component,
+of a component, rendered by Owl. It only work on a html element tagged by the
-tagged by the `t-ref` directive:
+`t-ref` directive:
 ```xml
 <div>
-    <div t-ref="someDiv"/>
+    <input t-ref="someDiv"/>
-    <SubComponent t-ref="someComponent"/>
+    <span>hello</span>
 </div>
 ```
 In this example, the component will be able to access the `div` and the component
-`SubComponent` using the `useRef` hook:
+`SubComponent` with the `useRef` hook:
 ```js
 class Parent extends Component {
-  subRef = useRef("someComponent");
+  inputRef = useRef("someComponent");
  divRef = useRef("someDiv");
  someMethod() {
    // here, if component is mounted, refs are active:
-    // - this.divRef.el is the div HTMLElement
+    // - this.inputRef.el is the input HTMLElement
    // - this.subRef.comp is the instance of the sub component
    // - this.subRef.el is the root HTML node of the sub component (i.e. this.subRef.comp.el)
  }
 }
 ```
-As shown by the example above, html elements are accessed by using the `el`
+As shown by the example above, the actual HTMLElement instance is accessed with
-key, and components references are accessed with `comp`.
+the `el` key.
 Notes:
 - if used on a component, the reference will be set in the `refs`
  variable between `willPatch` and `patched`,
 - on a component, accessing `ref.el` will get the root node of the component.
 The `t-ref` directive also accepts dynamic values with string interpolation
-(like the [`t-attf-`](qweb_templating_language.md#dynamic-attributes) and
+(like the [`t-attf-`](templates.md#dynamic-attributes) and
 `t-component` directives). For example,
 ```xml
@@ -343,13 +161,12 @@ all components. But sometimes, we want to _scope_ that knowledge to a subtree.
 For example, if we have a form view component, maybe we would like to make some
 `model` object available to all sub components, but not to the whole application.
 This is where the `useSubEnv` hook may be useful: it lets a component add some
-information to the environment in a way that only the component and its children
+information to the environment in a way that only its children
 can access it:
 ```js
 class FormComponent extends Component {
-  constructor(...args) {
+  setup() {
    super(...args);
    const model = makeModel();
    useSubEnv({ model });
  }
@@ -377,70 +194,134 @@ useExternalListener(window, "click", this.closeMenu);
 The `useComponent` hook is useful as a building block for some customized hooks,
 that may need a reference to the component calling them.
 ```js
 function useSomething() {
  const component = useComponent();
  // now, component is bound to the instance of the current component
 }
 ```
 ### `useEnv`
 The `useEnv` hook is useful as a building block for some customized hooks,
 that may need a reference to the env of the component calling them.
 ### Making customized hooks
 Hooks are a wonderful way to organize the code of a complex component by feature
 instead of by lifecycle methods. They are like mixins, except that they can be
 easily composed together.
 But, like every good things in life, hooks should be used with moderation. They are
 not the solution to every problem.
 - they may be overkill: if your component needs to perform some action specific
  to itself (so, the specific code does not need to be shared), there is nothing
  wrong with a simple class method:
 ```js
-  // maybe overkill
+function useSomething() {
  class A extends Component {
    constructor(...args) {
      super(...args);
      useMySpecificHook();
    }
  }
  // ok
  class B extends Component {
    constructor(...args) {
      super(...args);
      this.performSpecificTask();
    }
  }
  ```
  Note that the second solution is easier to extend in sub components.
 - they may be harder to test: if a customized hook injects some external side
  effect dependency, then it is harder to test without doing some non obvious
  manipulation. For example, assume that we want to give a reference to a
  router in a `useRouter` hook. We could do this:
  ```js
  const router = new Router(...);
  function useRouter() {
      return router;
  }
  ```
  As you can see, this does not _hook_ into the internal of the component. It
  simply returns a global object, which is difficult to mock.
  A better way would be to do something like this: get the reference from the
  environment.
  ```js
  function useRouter() {
  const env = useEnv();
-    return env.router;
+  // now, env is bound to the env of the current component
 }
 ```
-  This means that we give control to the application developer to create the
+### `useEffect`
-  router, which is good, so they can set it up, subclass it, ... And then, to
+
-  test our components, we can just add a mock router in the environment.
+This hook will run a callback when a component is mounted and patched, and
 will run a cleanup function before patching and before unmounting the
 the component (only if some dependencies have changed).
 It has almost the same API as the React `useEffect` hook, except that the dependencies
 are defined by a function instead of just the dependencies.
 The `useEffect` hook takes two function: the effect function and the dependency
 function. The effect function perform some task and return (optionally) a cleanup
 function. The dependency function returns a list of dependencies. If any of these
 dependencies changes, then the current effect will be cleaned up and reexecuted.
 Here is an example without any dependencies:
 ```js
 useEffect(
  () => {
    window.addEventListener("mousemove", someHandler);
    return () => window.removeEventListener("mousemove", someHandler);
  },
  () => []
 );
 ```
 In the example above, the dependency list is empty, so the effect is only cleaned
 up when the component is unmounted.
 If the dependency function is skipped, then the effect will be cleaned up and
 rerun at every patch.
 ## Example: mouse position
 Here is the classical example of a non trivial hook to track the mouse position.
 ```js
 const { useState, onWillDestroy, Component } = owl;
 // We define here a custom behaviour: this hook tracks the state of the mouse
 // position
 function useMouse() {
  const position = useState({ x: 0, y: 0 });
  function update(e) {
    position.x = e.clientX;
    position.y = e.clientY;
  }
  window.addEventListener("mousemove", update);
  onWillDestroy(() => {
    window.removeEventListener("mousemove", update);
  });
  return position;
 }
 // Main root component
 class Root extends Component {
  static template = xml`<div>Mouse: <t t-esc="mouse.x"/>, <t t-esc="mouse.y"/></div>`;
  // this hooks is bound to the 'mouse' property.
  mouse = useMouse();
 }
 ```
 Note that we use the prefix `use` for hooks, just like in React. This is just
 a convention.
 ## Example: autofocus
 Hooks can be combined to create the desired effect. For example, the following
 hook combines the `useRef` hook with the `onPatched` and `onMounted` functions
 to create an easy way to focus an input whenever it appears in the DOM:
 ```js
 function useAutofocus(name) {
  let ref = useRef(name);
  let isInDom = false;
  function updateFocus() {
    if (!isInDom && ref.el) {
      isInDom = true;
      const current = ref.el.value;
      ref.el.value = "";
      ref.el.focus();
      ref.el.value = current;
    } else if (isInDom && !ref.el) {
      isInDom = false;
    }
  }
  onPatched(updateFocus);
  onMounted(updateFocus);
 }
 ```
 This hook takes the name of a valid `t-ref` directive, which should be present
 in the template. It then checks whenever the component is mounted or patched if
 the reference is not valid, and in this case, it will focus the node element.
 This hook can be used like this:
 ```js
 class SomeComponent extends Component {
  static template = xml`
    <div>
        <input />
        <input t-ref="myinput"/>
    </div>`;
  setup() {
    useAutofocus("myinput");
  }
 }
 ```
@@ -0,0 +1,92 @@
 # 🦉 Form Input Bindings 🦉
 It is very common to need to be able to read the value out of an html `input` (or
 `textarea`, or `select`) in order to use it (note: it does not need to be in a
 form!). A possible way to do this is to do it by hand:
 ```js
 class Form extends owl.Component {
  state = useState({ text: "" });
  _updateInputValue(event) {
    this.state.text = event.target.value;
  }
 }
 ```
 ```xml
 <div>
  <input t-on-input="_updateInputValue" />
  <span t-esc="state.text" />
 </div>
 ```
 This works. However, this requires a little bit of _plumbing_ code. Also, the
 plumbing code is slightly different if you need to interact with a checkbox,
 or with radio buttons, or with select tags.
 To help with this situation, Owl has a builtin directive `t-model`: its value
 should be an observed value in the component (usually `state.someValue`). With
 the `t-model` directive, we can write a shorter code, equivalent to the previous
 example:
 ```js
 class Form extends owl.Component {
  state = { text: "" };
 }
 ```
 ```xml
 <div>
  <input t-model="state.text" />
  <span t-esc="state.text" />
 </div>
 ```
 The `t-model` directive works with `<input>`, `<input type="checkbox">`,
 `<input type="radio">`, `<textarea>` and `<select>`:
 ```xml
 <div>
    <div>Text in an input: <input t-model="state.someVal"/></div>
    <div>Textarea: <textarea t-model="state.otherVal"/></div>
    <div>Boolean value: <input type="checkbox" t-model="state.someFlag"/></div>
    <div>Selection:
        <select t-model="state.color">
            <option value="">Select a color</option>
            <option value="red">Red</option>
            <option value="blue">Blue</option>
        </select>
    </div>
    <div>
        Selection with radio buttons:
        <span>
            <input type="radio" name="color" id="red" value="red" t-model="state.color"/>
            <label for="red">Red</label>
        </span>
        <span>
            <input type="radio" name="color" id="blue" value="blue" t-model="state.color" />
            <label for="blue">Blue</label>
        </span>
    </div>
 </div>
 ```
 Like event handling, the `t-model` directive accepts the following modifiers:
 | Modifier  | Description                                                          |
 | --------- | -------------------------------------------------------------------- |
 | `.lazy`   | update the value on the `change` event (default is on `input` event) |
 | `.number` | try to parse the value to a number (using `parseFloat`)              |
 | `.trim`   | trim the resulting value                                             |
 For example:
 ```xml
 <input t-model.lazy="state.someVal" />
 ```
 These modifiers can be combined. For instance, `t-model.lazy.number` will only
 update a number whenever the change is done.
 Note: the online playground has an example to show how it works.
@@ -1,133 +0,0 @@
 # 🦉 Miscellaneous 🦉
 ## Content
 - [Portal](#portal)
 - [AsyncRoot](#asyncroot)
 ## `Portal`
 ### Overview
 The component `Portal` is meant to be used as a transparent way to 'teleport' a piece
 of DOM to the node represented by its sole `target` props.
 This component aims at helping the implementation of the needed infrastructure
 for modals (as in `bootstrap-modal`).
 ### Usage
 The content it will teleport is defined within the `<Portal>` node and
 internally uses the `default` [Slot](slots.md).
 This slot must contain only **one** node, which in turn can have as many children as necessary.
 The element under which the content will be teleported is represented as a selector
 by the `target` props which only accepts a string as value.
 The `target` props only supports static selector, and is not meant to be passed to `Portal`
 as a variable. Namely, `<Portal target="'body'" />` is the intended use.
 By contrast, `<Portal target="state.target" />` is not supported.
 The component `Portal` has no particular state, rather it is meant to be a slave to its parent,
 and ultimately just a way for the parent to teleport a piece of its own DOM elsewhere.
 The `Portal`'s root node is always `<portal/>` and is placed where the teleported content
 _would have_ been. It is this element that the [teleported events](#expected-behaviors) are re-directed on.
 ### Example
 The canonic use-case is to implement a Dialog, where a Component may choose to break the natural
 workflow to help the user put in some data, which it could use later on.
 JavaScript:
 ```js
 const { Component, mount } = owl;
 const { Portal } = owl.misc;
 class TeleportedComponent extends Component {}
 class App extends Component {
  static components = { Portal, TeleportedComponent };
 }
 mount(App, { target: document.body });
 ```
 XML:
 ```xml
 <templates>
    <div t-name="TeleportedComponent">
        <span>I will move soon enough</span>
    </div>
    <div t-name="App">
        <span>I am like the rest of us</span>
        <Portal target="'body'">
            <TeleportedComponent />
        </Portal>
    </div>
 </templates>
 ```
 In this example, the `Portal` component will teleport the `TeleportedComponent`'s `div` as a child of the `body`.
 `TeleportedComponent` is acting as a Dialog here.
 The resulting DOM will look like:
 ```xml
 <body>
    <div>
        <span>I am like the rest of us</span>
        <portal></portal>
    </div>
    <div>
        <span>I will move soon enough</span>
    </div>
 </body>
 ```
 ### Expected Behaviors
 The teleported piece is updated as any other `Component`'s DOM and in the same sequence.
 Namely the teleported piece will be updated in function of its parents components, and patched as
 a normal child.
 The [_business_ events](event_handling.md#business-dom-events) triggered by a child component will be stopped
 to not bubble outside of the `target`. They will, on the other hand, be re-directed onto the
 `Portal`'s root node and bubble up the DOM as if it were triggered by a regular child component.
 Beware that those re-directed events are copies of the original event.
 They have:
 - The same payload.
 - The same `originalComponent` than their original counterpart,
  that is the actual Component that triggered it.
 - A **different** `target` property than their original counterpart.
  The `target` of a re-directed event is necessarily the `Portal`'s root node.
 Pure DOM events do not follow this pattern and are free to bubble their natural, unaltered way
 up to the `body`.
 ## `AsyncRoot`
 When this component is used, a new rendering sub tree is created, such that the
 rendering of that component (and its children) is not tied to the rendering of
 the rest of the interface. It can be used on an asynchronous component, to
 prevent it from delaying the rendering of the whole interface, or on a
 synchronous one, such that its rendering isn't delayed by other (asynchronous)
 components. Note that this directive has no effect on the first rendering, but
 only on subsequent ones (triggered by state or props changes).
 ```xml
 <div t-name="ParentComponent">
  <SyncChild />
  <AsyncRoot>
     <AsyncChild/>
  </AsyncRoot>
 </div>
 ```
 The `AsyncRoot` assumes that there is exactly one root node inside it. It can
 be a dom node or a component.
@@ -1,60 +0,0 @@
 # 🦉 Mounting an application 🦉
 ## Content
 - [Overview](#overview)
 - [API](#api)
 ## Overview
 Mounting an Owl application is done by using the `mount` method (available in
 `owl.mount` if you are using the iife build, or it can be directly imported
 from `owl` if you are using a module system):
 ```js
 const mount = { owl }; // if owl is available as an object
 const env = { ... };
 const app = await mount(MyComponent, { target: document.body, env });
 ```
 Another example:
 ```js
 const config = {
  env: ...,
  props: ...,
  target: document.body,
  position: "self",
 };
 const app = await mount(App, config);
 ```
 A common way to initialize an application is to first setup an environment,
 then to call the `mount` method.
 ## API
 Mount takes two parameters:
 - `C`, which should be a component class (NOT instance),
 - `params`, which is an object with the following keys:
  - `target (HTMLElement | DocumentFragment)`: the target of the mount operation
  - `env (optional, Env)` an environment
  - `position (optional, "first-child" | "last-child" | "self")` the position
    where it should be mounted (see below for more informations)
  - `props (optional, any)`: some initial values that are given as props. Useful
    when the root component is configurable, or when testing sub components
 Here are the various positions supported by Owl:
 - `first-child`: with this option, the component will be prepended inside the target,
 - `last-child` (default value): with this option, the component will be
  appended in the target element,
 - `self`: the target will be used as the root element for the component. This
  means that the target has to be an HTMLElement (and not a document fragment).
  In this situation, it is possible that the component cannot be unmounted. For
  example, if its target is `document.body`.
 The `mount` method returns a promise that resolves to the instance of the created
 component.
@@ -1,52 +0,0 @@
 # 🦉 Observer 🦉
 Owl needs to be able to react to state changes. For example, whenever the state
 of a component is changed, Owl needs to rerender it. To help with that, there is
 an Observer class. Its job is to observe the state of an object (or array), and
 to react to any change. The observer is implemented with the native `Proxy`
 object. Note that this means that it will not work on older browsers.
 Note that the `Observer` is used by the `useState` and `useContext` hooks. This
 is the way most Owl applications will create observers. For the majority of
 use cases, there is no need to directly instantiate an observer.
 ## Example
 For example, this code will display `update` in the console:
 ```javascript
 const observer = new owl.core.Observer();
 observer.notifyCB = () => console.log("update");
 const obj = observer.observe({ a: { b: 1 } });
 obj.a.b = 2;
 ```
 This example shows that an observer can observe nested properties.
 ## Reference
 **observe** An observer can observe multiple values with the `observe` method.
 This method takes an object or an array as its argument and will return a proxy
 (which is mapped to the initial object/array). With this proxy, the observer
 can detect whenever any internal value is changed.
 **Registering a callback** Whenever an observer sees a state change, it will
 call its `notifyCB` method. No additional information is given to the callback.
 **deepRevNumber** Each observed value has an internal revision number, which
 is incremented every time the value is observed. Sometimes, it can be useful
 to obtain that number:
 ```js
 const observer = new owl.core.Observer();
 const obj = observer.observe({ a: { b: 1 } });
 observer.revNumber(obj.a); // 1
 obj.a.b = 2;
 observer.revNumber(obj.a); // 2
 ```
 The `revNumber` can also return 0, which indicates that the value is not
 observed.
@@ -0,0 +1,17 @@
 # 🦉 Portal 🦉
 It is sometimes useful to be able to render some content outside the boundaries
 of a component. To do that, Owl provides a special directive: `t-portal`:
 ```js
 class SomeComponent extends Component {
  static template = xml`
      <div>this is inside the component</div>
      <div t-portal="'body'">and this is outside</div>
    `;
 }
 ```
 The `t-portal` directive takes a valid css selector as argument. The content of
 the portalled template will be mounted at the corresponding location. Note that
 Owl need to insert an empty text node at the location of the portalled content.
@@ -4,8 +4,11 @@
 - [Overview](#overview)
 - [Definition](#definition)
- [Good Practices](#good-practices)
+- [Binding function props](#binding-function-props)
 - [Dynamic Props](#dynamic-props)
 - [Default Props](#default-props)
 - [Props validation](#props-validation)
 - [Good Practices](#good-practices)
 ## Overview
@@ -38,8 +41,6 @@ The `props` object is made of every attributes defined on the template, with the
 following exceptions:
 - every attribute starting with `t-` are not props (they are QWeb directives),
 - `style` and `class` attributes are excluded as well (they are applied by Owl on
  the root element of the component).
 In the following example:
@@ -47,7 +48,6 @@ In the following example:
 <div>
    <ComponentA a="state.a" b="'string'"/>
    <ComponentB t-if="state.flag" model="model"/>
    <ComponentC style="color:red;" class="left-pane" />
 </div>
 ```
@@ -55,7 +55,182 @@ the `props` object contains the following keys:
 - for `ComponentA`: `a` and `b`,
 - for `ComponentB`: `model`,
- for `ComponentC`: empty object
+
 ## Binding function props
 It is common to have the need to pass a callback as a prop. Since Owl components
 are class based, the callback frequently needs to be bound to its owner component.
 So, one can do this:
 ```js
 class SomeComponent extends Component {
  static template = xml`
    <div>
      <Child callback="doSomething"/>
    </div>`;
  setup() {
    this.doSomething = this.doSomething.bind(this);
  }
  doSomething() {
    // ...
  }
 }
 ```
 However, this is such a common use case that Owl provides a special suffix to do
 just that: `.bind`. This looks like this:
 ```js
 class SomeComponent extends Component {
  static template = xml`
    <div>
      <Child callback.bind="doSomething"/>
    </div>`;
  doSomething() {
    // ...
  }
 }
 ```
 ## Dynamic Props
 The `t-props` directive can be used to specify totally dynamic props:
 ```xml
 <div t-name="ParentComponent">
    <Child t-props="some.obj"/>
 </div>
 ```
 ```js
 class ParentComponent {
  static components = { Child };
  some = { obj: { a: 1, b: 2 } };
 }
 ```
 ## Default Props
 If the static `defaultProps` property is defined, it will be used to complete
 props received by the parent, if missing.
 ```js
 class Counter extends owl.Component {
  static defaultProps = {
    initialValue: 0,
  };
  ...
 }
 ```
 In the example above, the `initialValue` props is now by default set to 0.
 ## Props Validation
 As an application becomes complex, it may be quite unsafe to define props in an informal way. This leads to two issues:
 - hard to tell how a component should be used, by looking at its code.
 - unsafe, it is easy to send wrong props into a component, either by refactoring a component, or one of its parents.
 A props type system solves both issues, by describing the types and shapes
 of the props. Here is how it works in Owl:
 - `props` key is a static key (so, different from `this.props` in a component instance)
 - it is optional: it is ok for a component to not define a `props` key.
 - props are validated whenever a component is created/updated
 - props are only validated in `dev` mode (see [how to configure an app](app.md#configuration))
 - if a key does not match the description, an error is thrown
 - it validates keys defined in (static) `props`. Additional keys given by the
  parent will cause an error.
 For example:
 ```js
 class ComponentA extends owl.Component {
    static props = ['id', 'url'];
    ...
 }
 class ComponentB extends owl.Component {
  static props = {
    count: {type: Number},
    messages: {
      type: Array,
      element: {type: Object, shape: {id: Boolean, text: String }
    },
   date: Date,
   combinedVal: [Number, Boolean]
  };
  ...
 }
 ```
 - it is an object or a list of strings
 - a list of strings is a simplified props definition, which only lists the name
  of the props. Also, if the name ends with `?`, it is considered optional.
 - all props are by default required, unless they are defined with `optional: true`
  (in that case, validation is only done if there is a value)
 - valid types are: `Number, String, Boolean, Object, Array, Date, Function`, and all
  constructor functions (so, if you have a `Person` class, it can be used as a type)
 - arrays are homogeneous (all elements have the same type/shape)
 For each key, a `prop` definition is either a boolean, a constructor, a list of constructors, or an object:
 - a boolean: indicate that the props exists, and is mandatory.
 - a constructor: this should describe the type, for example: `id: Number` describe
  the props `id` as a number
 - a list of constructors. In that case, this means that we allow more than one
  type. For example, `id: [Number, String]` means that `id` can be either a string
  or a number.
 - an object. This makes it possible to have more expressive definition. The following sub keys are then allowed (but not mandatory):
  - `type`: the main type of the prop being validated
  - `element`: if the type was `Array`, then the `element` key describes the type of each element in the array. If it is not set, then we only validate the array, not its elements,
  - `shape`: if the type was `Object`, then the `shape` key describes the interface of the object. If it is not set, then we only validate the object, not its elements,
  - `validate`: this is a function which should return a boolean to determine if
    the value is valid or not. Useful for custom validation logic.
 Examples:
 ```js
  // only the existence of those 3 keys is documented
  static props = ['message', 'id', 'date'];
 ```
 ```js
  // size is optional
  static props = ['message', 'size?'];
 ```
 ```js
  static props = {
    messageIds: {type: Array, element: Number},  // list of number
    otherArr: {type: Array},   // just array. no validation is made on sub elements
    otherArr2: Array,   // same as otherArr
    someObj: {type: Object},  // just an object, no internal validation
    someObj2: {
      type: Object,
      shape: {
        id: Number,
        name: {type: String, optional: true},
        url: String
      ]},    // object, with keys id (number), name (string, optional) and url (string)
    someFlag: Boolean,     // a boolean, mandatory (even if `false`)
    someVal: [Boolean, Date],   // either a boolean or a date
    otherValue: true,     // indicates that it is a prop
    kindofsmallnumber: {
      type: Number,
      validate: n => (0 <= n && n <= 10)
    },
    size: {
      validate:  e => ["small", "medium", "large"].includes(e)
    },
  };
 ```
 ## Good Practices
@@ -78,20 +253,3 @@ sent to the parent (for example, with an event).
 Any value can go in a props. Strings, objects, classes, or even callbacks could
 be given to a child component (but then, in the case of callbacks, communicating
 with events seems more appropriate).
 ## Dynamic Props
 The `t-props` directive can be used to specify totally dynamic props:
 ```xml
 <div t-name="ParentComponent">
    <Child t-props="some.obj"/>
 </div>
 ```
 ```js
 class ParentComponent {
  static components = { Child };
  some = { obj: { a: 1, b: 2 } };
 }
 ```
@@ -1,103 +0,0 @@
 # 🦉 Props Validation 🦉
 As an application becomes complex, it may be quite unsafe to define props in an informal way. This leads to two issues:
 - hard to tell how a component should be used, by looking at its code.
 - unsafe, it is easy to send wrong props into a component, either by refactoring a component, or one of its parents.
 A props type system solves both issues, by describing the types and shapes
 of the props. Here is how it works in Owl:
 - `props` key is a static key (so, different from `this.props` in a component instance)
 - it is optional: it is ok for a component to not define a `props` key.
 - props are validated whenever a component is created/updated
 - props are only validated in `dev` mode (see [config page](config.md#mode))
 - if a key does not match the description, an error is thrown
 - it validates keys defined in (static) `props`. Additional keys given by the
  parent will cause an error.
 For example:
 ```js
 class ComponentA extends owl.Component {
    static props = ['id', 'url'];
    ...
 }
 class ComponentB extends owl.Component {
  static props = {
    count: {type: Number},
    messages: {
      type: Array,
      element: {type: Object, shape: {id: Boolean, text: String }
    },
   date: Date,
   combinedVal: [Number, Boolean]
  };
  ...
 }
 ```
 - it is an object or a list of strings
 - a list of strings is a simplified props definition, which only lists the name
  of the props. Also, if the name ends with `?`, it is considered optional.
 - all props are by default required, unless they are defined with `optional: true`
  (in that case, validation is only done if there is a value)
 - valid types are: `Number, String, Boolean, Object, Array, Date, Function`, and all
  constructor functions (so, if you have a `Person` class, it can be used as a type)
 - arrays are homogeneous (all elements have the same type/shape)
 For each key, a `prop` definition is either a boolean, a constructor, a list of constructors, or an object:
 - a boolean: indicate that the props exists, and is mandatory.
 - a constructor: this should describe the type, for example: `id: Number` describe
  the props `id` as a number
 - a list of constructors. In that case, this means that we allow more than one
  type. For example, `id: [Number, String]` means that `id` can be either a string
  or a number.
 - an object. This makes it possible to have more expressive definition. The following sub keys are then allowed (but not mandatory):
  - `type`: the main type of the prop being validated
  - `element`: if the type was `Array`, then the `element` key describes the type of each element in the array. If it is not set, then we only validate the array, not its elements,
  - `shape`: if the type was `Object`, then the `shape` key describes the interface of the object. If it is not set, then we only validate the object, not its elements,
  - `validate`: this is a function which should return a boolean to determine if
    the value is valid or not. Useful for custom validation logic.
 Examples:
 ```js
  // only the existence of those 3 keys is documented
  static props = ['message', 'id', 'date'];
 ```
 ```js
  // size is optional
  static props = ['message', 'size?'];
 ```
 ```js
  static props = {
    messageIds: {type: Array, element: Number},  // list of number
    otherArr: {type: Array},   // just array. no validation is made on sub elements
    otherArr2: Array,   // same as otherArr
    someObj: {type: Object},  // just an object, no internal validation
    someObj2: {
      type: Object,
      shape: {
        id: Number,
        name: {type: String, optional: true},
        url: String
      ]},    // object, with keys id (number), name (string, optional) and url (string)
    someFlag: Boolean,     // a boolean, mandatory (even if `false`)
    someVal: [Boolean, Date],   // either a boolean or a date
    otherValue: true,     // indicates that it is a prop
    kindofsmallnumber: {
      type: Number,
      validate: n => (0 <= n && n <= 10)
    },
    size: {
      validate:  e => ["small", "medium", "large"].includes(e)
    },
  };
 ```
@@ -1,153 +0,0 @@
 # 🦉 QWeb Engine 🦉
 ## Content
 - [Overview](#overview)
 - [Reference](#reference)
 ## Overview
 [QWeb](https://www.odoo.com/documentation/13.0/reference/qweb.html) is the primary
 templating engine used by Odoo. The QWeb class in the OWL project is an
 implementation of that specification with a few interesting points:
 - it compiles templates into functions that output a virtual DOM instead of a
  string. This is necessary for the component system.
 - it has a few extra directives: `t-component`, `t-on`, ...
 We present in this section the engine, not the templating language.
 ## Reference
 This section is about the javascript code that implements the `QWeb` specification.
 Owl exports a `QWeb` class in `owl.QWeb`. To use it, it just needs to be
 instantiated:
 ```js
 const qweb = new owl.QWeb();
 ```
 Its API is quite simple:
 - **`constructor(config)`**: constructor. Takes an optional configuration object
  with an optional `templates` string to add initial
  templates (see `addTemplates` for more information on format of the string)
  and an optional `translateFn` translate function (see the section on
  [translations](#translations)).
  ```js
  const qweb = new owl.QWeb({ templates: TEMPLATES, translateFn: _t });
  ```
 - **`addTemplate(name, xmlStr, allowDuplicate)`**: add a specific template.
  ```js
  qweb.addTemplate("mytemplate", "<div>hello</div>");
  ```
  If the optional `allowDuplicate` is set to `true`, then `QWeb` will simply
  ignore templates added for a second time. Otherwise, `QWeb` will crash.
 - **`addTemplates(xmlStr)`**: add a list of templates (identified by `t-name`
  attribute).
  ```js
  const TEMPLATES = `
    <templates>
      <div t-name="App" class="main">main</div>
      <div t-name="OtherComponent">other component</div>
    </templates>`;
  qweb.addTemplates(TEMPLATES);
  ```
 - **`render(name, context, extra)`**: renders a template. This returns a `vnode`,
  which is a virtual representation of the DOM (see [vdom doc](../miscellaneous/vdom.md)).
  ```js
  const vnode = qweb.render("App", component);
  ```
 - **`renderToString(name, context)`**: renders a template, but returns an html
  string.
  ```js
  const str = qweb.renderToString("someTemplate", somecontext);
  ```
 - **`registerTemplate(name, template)`**: static function to register a global
  QWeb template. This is useful for commonly used components accross the
  application, and for making a template available to an application without
  having a reference to the actual QWeb instance.
  ```js
  QWeb.registerTemplate("mytemplate", `<div>some template</div>`);
  ```
 - **`registerComponent(name, Component)`**: static function to register an OWL Component
  to QWeb's global registry. Globally registered Components can be used in
  templates (see the `t-component` directive). This is useful for commonly used
  components accross the application.
  ```js
  class Dialog extends owl.Component { ... }
  QWeb.registerComponent("Dialog", Dialog);
  ...
  class ParentComponent extends owl.Component { ... }
  qweb.addTemplate("ParentComponent", "<div><Dialog/></div>");
  ```
 In some way, a `QWeb` instance is the core of an Owl application. It is the only
 mandatory element of an [environment](environment.md). As such, it
 has an extra responsibility: it can act as an event bus for internal communication
 between Owl classes. This is the reason why `QWeb` actually extends [EventBus](event_bus.md).
 ### Translations
 take care of this and "cherry-pick" 8464a1b04e7469434f9dcb3d68a543f58cb61b8e
 If properly setup, Owl QWeb engine can translate all rendered templates. To do
 so, it needs a translate function, which takes a string and returns a string.
 For example:
 ```js
 const translations = {
  hello: "bonjour",
  yes: "oui",
  no: "non",
 };
 const translateFn = (str) => translations[str] || str;
 const qweb = new QWeb({ translateFn });
 ```
 Once setup, all rendered templates will be translated using `translateFn`:
 - each text node will be replaced with its translation,
 - each of the following attribute values will be translated as well: `title`,
  `placeholder`, `label` and `alt`,
 - translating text nodes can be disabled with the special attribute `t-translation`,
  if its value is `off`.
 So, with the above `translateFn`, the following templates:
 ```xml
 <div>hello</div>
 <div t-translation="off">hello</div>
 <div>Are you sure?</div>
 <input placeholder="hello" other="yes"/>
 ```
 will be rendered as:
 ```xml
 <div>bonjour</div>
 <div>hello</div>
 <div>Are you sure?</div>
 <input placeholder="bonjour" other="yes"/>
 ```
 Note that the translation is done during the compilation of the template, not
 when it is rendered.
@@ -0,0 +1,80 @@
 # 🦉 Reactivity 🦉
 ## Content
 - [Overview](#overview)
 - [`useState`](#usestate)
 - [`reactive`](#reactive)
 ## Overview
 Reactivity is a big topic in javascript frameworks. The goal is to provide a
 simple way to manipulate state, in such a way that the interface automatically
 update accordingly to state changes. Also, we obviously want this to happen in
 a performant way.
 To solve this issue, Owl provides two reactivity primitives:
 - `reactive`, which returns a proxy to its first argument, and tracks all read/update
  operation going through it,
 - `useState`: a hook, that internally uses `reactive`, and is linked to its
  owner component: any read operation will be tracked (key by key), and any
  updates to these tracked values will cause the component to be rerendered.
 Most of the time, the `useState` hook is the best solution.
 ## `useState`
 Let us start by an example of how `useState` could be used:
 ```js
 class Counter extends Component {
  static template = xml`
    <div t-on-click="increment">
      <t t-esc="state.value"/>
    </div>`;
  setup() {
    this.state = useState({ value: 0 });
  }
  increment() {
    this.state.value++;
  }
 }
 ```
 If one were to use a simple state object, Owl would not be aware that the value
 was changed and that the component should be rerendered. With the `useState`
 hook, `this.state` is now a reactive object, so this component works as expected.
 ## `reactive`
 The `reactive` function is the basic reactivity primitive. It takes an object
 or an array as first argument, and optionally, a function as the second argument.
 The function will be called whenever any tracked value is updated.
 ```js
 const obj = reactive({ a: 1 }, () => console.log("changed"));
 obj.a = 2; // does not log anything: the 'a' key was not read
 console.log(obj.a); // log 2, and reads the 'a' key => it is now tracked
 obj.a = 3; // log 'changed' because we updated a tracked value
 ```
 An important property of reactive objects is that they can be reobserved: this
 will create an independant proxy that tracks another set of keys:
 ```js
 const obj1 = reactive({ a: 1, b: 2 }, () => console.log("observer 1"));
 const obj2 = reactive(obj1, () => console.log("observer 2"));
 console.log(obj1.a); // log 1, and reads the 'a' key => it is now tracked by observer 1
 console.log(obj1.b); // log 2, and 'b' is now tracked by observer 1
 console.log(obj2.b); // log 2, and 'b' is now tracked by observer 1
 obj2.a = 3; // log 'observer1', because observer2 does not track a
 obj2.b = 3; // log 'observer1' and 'observer2'
 ```
 Obviously, one can use `reactive` on the result of a `useState` if wanted, this
 is the proper way to watch for some state changes.
@@ -0,0 +1,37 @@
 # 🦉 References 🦉
 The `useRef` hook is useful when we need a way to interact with some inside part
 of a component, rendered by Owl. It can work either on a DOM node, or on a component,
 targeted by the `t-ref` directive. See the [hooks section](hooks.md#useref) for
 more detail.
 As a short example, here is how we could set the focus on a given input:
 ```xml
 <div>
    <input t-ref="input"/>
    <button t-on-click="focusInput">Click</button>
 </div>
 ```
 ```js
 import { useRef } from "owl/hooks";
 class SomeComponent extends Component {
  inputRef = useRef("input");
  focusInput() {
    this.inputRef.el.focus();
  }
 }
 ```
 Be aware that the `el` property will only be set when the target of the `t-ref`
 directive is mounted in the DOM. Otherwise, it will be set to `null`.
 The `useRef` hook cannot be used to get a reference to an instance of a sub
 component.
 Note that this example uses the suffix `ref` to name the reference. This
 is not mandatory, but it is a useful convention, so we do not forget that it is
 a reference object.
@@ -1,184 +0,0 @@
 # 🦉 Tags 🦉
 ## Content
 - [Overview](#overview)
 - [`xml` tag](#xml-tag)
 - [`css` tag](#css-tag)
 ## Overview
 Tags are very small helpers intended to make it easy to write inline templates
 or styles. There are currently two tags: `css` and `xml`. With these functions,
 it is possible to write [single file components](../learning/how_to_write_sfc.md).
 ## XML tag
 The `xml` tag is certainly the most useful tag. It is used to define an inline
 QWeb template for a component. Without tags, creating a standalone component
 would look like this:
 ```js
 import { Component } from 'owl'
 const name = 'some-unique-name';
 const template = `
    <div>
        <span t-if="somecondition">text</span>
        <button t-on-click="someMethod">Click</button>
    </div>
 `;
 QWeb.registerTemplate(name, template);
 class MyComponent extends Component {
    static template = name;
    ...
 }
 ```
 With tags, this process is slightly simplified. The name is uniquely generated,
 and the template is automatically registered:
 ```js
 const { Component } = owl;
 const { xml } = owl.tags;
 class MyComponent extends Component {
    static template = xml`
        <div>
            <span t-if="somecondition">text</span>
            <button t-on-click="someMethod">Click</button>
        </div>
    `;
    ...
 }
 ```
 ## CSS tag
 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>`.
 Note that to make it more useful, like other css preprocessors, the `css` tag
 accepts a small extension of the css specification: css scopes can be nested,
 and the rules will then be expanded by the `css` helper:
 ```scss
 .my-component {
  display: block;
  .sub-component h {
    color: red;
  }
 }
 ```
 will be formatted as:
 ```css
 .my-component {
  display: block;
 }
 .my-component .sub-component h {
  color: red;
 }
 ```
 This extension brings another useful feature: the `&` selector which refers to
 the parent selector. For example, we want our component to be red when hovered.
 We would like to write something like:
 ```scss
 .my-component {
  display: block;
  :hover {
    color: red;
  }
 }
 ```
 but it will be formatted as:
 ```css
 .my-component {
  display: block;
 }
 .my-component :hover {
  color: red;
 }
 ```
 The `&` selector can be used to solve this problem:
 ```scss
 .my-component {
  display: block;
  &:hover {
    color: red;
  }
 }
 ```
 will be formatted as:
 ```css
 .my-component {
  display: block;
 }
 .my-component:hover {
  color: red;
 }
 ```
 Now, there is no additional processing done by the `css` tag. However, since it
 is done in javascript at runtime, we actually have more power. For example:
 1. sharing values between javascript and css:
 ```js
 import { theme } from "./theme";
 class MyComponent extends Component {
  static template = xml`<div class="my-component">...</div>`;
  static style = css`
    .my-component {
      color: ${theme.MAIN_COLOR};
      background-color: ${theme.SECONDARY_color};
    }
  `;
 }
 ```
 2. scoping rules to the current component:
 ```js
 import { generateUUID } from "./utils";
 const uuid = generateUUID();
 class MyComponent extends Component {
  static template = xml`<div data-o-${uuid}="">...</div>`;
  static style = css`
    [data-o-${uuid}] {
      color: red;
    }
  `;
 }
 ```
@@ -1,12 +1,11 @@
-# 🦉 QWeb Templating Language🦉
+# 🦉 Templates 🦉
 ## Content
 - [Overview](#overview)
 - [Directives](#directives)
- [Reference](#reference)
+- [QWeb Template reference](#qweb-template-reference)
  - [White Spaces](#white-spaces)
  - [Root Nodes](#root-nodes)
  - [Expression Evaluation](#expression-evaluation)
  - [Static html Nodes](#static-html-nodes)
  - [Outputting Data](#outputting-data)
@@ -16,17 +15,19 @@
  - [Dynamic Class Attribute](#dynamic-class-attribute)
  - [Dynamic Tag Names](#dynamic-tag-names)
  - [Loops](#loops)
-  - [Rendering Sub Templates](#rendering-sub-templates)
+  - [Sub Templates](#sub-templates)
  - [Dynamic Sub Templates](#dynamic-sub-templates)
  - [Translations](#translations)
  - [Debugging](#debugging)
 - [Fragments](#fragments)
 - [Inline templates](#inline-templates)
 - [Rendering svg](#rendering-svg)
 ## Overview
-[QWeb](https://www.odoo.com/documentation/13.0/reference/qweb.html) is the primary
+Owl templates are describe using the [QWeb](https://www.odoo.com/documentation/13.0/reference/qweb.html) specification. It is based on the XML format, and used
 templating engine used by Odoo. It is based on the XML format, and used
 mostly to generate HTML. In OWL, QWeb templates are compiled into functions that
-generate a virtual dom representation of the HTML.
+generate a virtual dom representation of the HTML. Also, since Owl is a live
 component system, there are additional directives specific to Owl (such as `t-on`).
 ```xml
 <div>
@@ -54,33 +55,32 @@ extensions.
 For reference, here is a list of all standard QWeb directives:
 | Name                           | Description                                                     |
-| ------------------------------ | -------------------------------------------------------------- |
+| ------------------------------ | --------------------------------------------------------------- |
 | `t-esc`                        | [Outputting safely a value](#outputting-data)                   |
-| `t-raw`                        | [Outputting value, without escaping](#outputting-data)         |
+| `t-out`                        | [Outputting value, possibly without escaping](#outputting-data) |
 | `t-set`, `t-value`             | [Setting variables](#setting-variables)                         |
 | `t-if`, `t-elif`, `t-else`,    | [conditionally rendering](#conditionals)                        |
 | `t-foreach`, `t-as`            | [Loops](#loops)                                                 |
 | `t-att`, `t-attf-*`, `t-att-*` | [Dynamic attributes](#dynamic-attributes)                       |
-| `t-call`                       | [Rendering sub templates](#rendering-sub-templates)            |
+| `t-call`                       | [Rendering sub templates](#sub-templates)                       |
 | `t-debug`, `t-log`             | [Debugging](#debugging)                                         |
-| `t-translation`                | [Disabling the translation of a node](#translations)           |
+| `t-translation`                | [Disabling the translation of a node](translations.md)          |
 | `t-name`                       | [Defining a template (not really a directive)](qweb_engine.md) |
 The component system in Owl requires additional directives, to express various
 needs. Here is a list of all Owl specific directives:
 | Name                     | Description                                                     |
-| ------------------------ | ------------------------------------------------------------------------------- |
+| ------------------------ | --------------------------------------------------------------- |
-| `t-component`, `t-props` | [Defining a sub component](component.md#composition)                            |
+| `t-component`, `t-props` | [Defining a sub component](component.md#sub-components)         |
-| `t-ref`                  | [Setting a reference to a dom node or a sub component](component.md#references) |
+| `t-ref`                  | [Setting a reference to a dom node or a sub component](refs.md) |
 | `t-key`                  | [Defining a key (to help virtual dom reconciliation)](#loops)   |
 | `t-on-*`                 | [Event handling](event_handling.md)                             |
-| `t-transition`           | [Defining an animation](animations.md#css-transitions)                          |
+| `t-portal`               | [Portal](portal.md)                                             |
 | `t-slot`                 | [Rendering a slot](slots.md)                                    |
-| `t-model`                | [Form input bindings](component.md#form-input-bindings)                         |
+| `t-model`                | [Form input bindings](input_bindings.md)                        |
 | `t-tag`                  | [Rendering nodes with dynamic tag name](#dynamic-tag-names)     |
-## Reference
+## QWeb Template Reference
 ### White Spaces
@@ -90,32 +90,6 @@ White spaces in a template are handled in a special way:
 - if a whitespace-only text node contains a linebreak, it is ignored
 - the previous rules do not apply if we are in a `<pre>` tag
 ### Root Nodes
 For many reasons, Owl QWeb templates should have a single root node. More
 precisely, the result of a template rendering should have a single root node:
 ```xml
 <!–– not ok: two root nodes ––>
 <t>
    <div>foo</div>
    <div>bar</div>
 </t>
 <!–– ok: result has one single root node ––>
 <t>
    <div t-if="someCondition">foo</div>
    <span t-else="">bar</span>
 </t>
 ```
 Extra root nodes will actually be ignored (even though they will be rendered
 in memory).
 Note: this does not apply to subtemplates (see the `t-call` directive). In that
 case, they will be inlined in the main template, and can actually have many
 root nodes.
 ### Expression Evaluation
 QWeb expressions are strings that will be processed at compile time. Each variable in
@@ -190,24 +164,29 @@ rendered with the value `value` set to `42` in the rendering context yields:
 <p>42</p>
 ```
-The `t-raw` directive is almost the same as `t-esc`, but without the escaping.
+The `t-out` directive is almost the same as `t-esc`, but possibly without the
-This is mostly useful to inject a raw html string somewhere. Obviously, this
+escaping. The difference is that the value received by the `t-out` directive
-is unsafe to do in general, and should only be used for strings known to be safe.
+will only be not-escaped if it has been marked as such, using the `markup`
 utility function:
-```xml
+For example, in the following component:
-<p><t t-raw="value"/></p>
+
 ```js
 const { markup, Component, xml } = owl;
 class SomeComponent extends Component {
  static template = xml`
    <t t-out="value1"/>
    <t t-out="value2"/>`;
  value1 = "<div>some text 1</div>";
  value2 = markup("<div>some text 2</div>");
 }
 ```
-rendered with the value `value` set to `<span>foo</span>` in the rendering context yields:
+The first `t-out` will act as a `t-esc` directive, which means that the content
-
+of `value1` will be escaped. However, since `value2` has been tagged as a markup,
-```html
+this will be injected as html.
 <p><span>foo</span></p>
 ```
 Note that since the content of the expression is not known beforehand, the `t-raw`
 directive has to parse the html (and convert it to a virtual dom structure) for
 each rendering. So, it will be much slower than a regular template. It is
 therefore advised to limit the use of `t-raw` whenever possible.
 ### Setting Variables
@@ -368,7 +347,7 @@ collection to iterate on, and a second parameter `t-as` providing the name to us
 for the current item of the iteration:
 ```xml
-<t t-foreach="[1, 2, 3]" t-as="i">
+<t t-foreach="[1, 2, 3]" t-as="i" t-key="i">
    <p><t t-esc="i"/></p>
 </t>
 ```
@@ -384,13 +363,17 @@ will be rendered as:
 Like conditions, `t-foreach` applies to the element bearing the directive’s attribute, and
 ```xml
-<p t-foreach="[1, 2, 3]" t-as="i">
+<p t-foreach="[1, 2, 3]" t-as="i" t-key="i">
    <t t-esc="i"/>
 </p>
 ```
 is equivalent to the previous example.
 An important difference should be made with the usual `QWeb` behaviour: Owl
 requires the presence of a `t-key` directive, to be able to properly reconcile
 renderings.
 `t-foreach` can iterate on an array (the current item will be the current value)
 or an object (the current item will be the current key).
@@ -416,7 +399,7 @@ into the global context.
 <t t-set="existing_variable" t-value="false"/>
 <!-- existing_variable now False -->
-<p t-foreach="Array(3)" t-as="i">
+<p t-foreach="Array(3)" t-as="i" t-key="i">
    <t t-set="existing_variable" t-value="true"/>
    <t t-set="new_variable" t-value="true"/>
    <!-- existing_variable and new_variable now true -->
@@ -430,17 +413,14 @@ Even though Owl tries to be as declarative as possible, the DOM does not fully
 expose its state declaratively in the DOM tree. For example, the scrolling state,
 the current user selection, the focused element or the state of an input are not
 set as attribute in the DOM tree. This is why we use a virtual dom
-algorithm to keep the actual DOM node as much as possible.
+algorithm to make sure we keep the actual DOM node instead of replacing it with
-
+a new one.
 However, in some situations, this is not enough, and we need to help Owl decide
 if an element is actually the same, or is a different element with the same
 properties.
 Consider the following situation: we have a list of two items `[{text: "a"}, {text: "b"}]`
 and we render them in this template:
 ```xml
-<p t-foreach="items" t-as="item"><t t-esc="item.text"/></p>
+<p t-foreach="items" t-as="item" t-key="item_index"><t t-esc="item.text"/></p>
 ```
 The result will be two `<p>` tags with text `a` and `b`. Now, if we swap them,
@@ -501,7 +481,7 @@ using the `...` javascript operator. For example:
 The `...` operator will convert the `Set` (or any other iterables) into a list,
 which will work with Owl QWeb.
-### Rendering Sub Templates
+### Sub Templates
 QWeb templates can be used for top level rendering, but they can also be used
 from within another template (to avoid duplication or give names to parts of
@@ -574,21 +554,6 @@ using string interpolation. For example:
 Here, the name of the template is obtained from the `template` value in the
 template rendering context.
 ### Translations
 By default, QWeb specify that templates should be translated. If this behaviour
 is not wanted, there is a `t-translation` directive which can turn off
 translations (if it is set to the `off` value), with the following rules:
 - each text node will be replaced with its translation,
 - each of the following attribute values will be translated as well: `title`,
  `placeholder`, `label` and `alt`,
 - translating text nodes can be disabled with the special attribute `t-translation`,
  if its value is `off`.
 See [here](qweb_engine.md#translations) for more information on how to setup a
 translate function in Owl QWeb.
 ### Debugging
 The javascript QWeb implementation provides two useful debugging directives:
@@ -611,3 +576,101 @@ will stop execution if the browser dev tools are open.
 ```
 will print 42 to the console.
 ## Fragments
 Owl 2 supports templates with an arbitrary number of root elements, or even just
 a text node. So, the following templates are all valid:
 ```xml
 hello owl. This is just a text node!
 ```
 ```xml
 <div>hello</div>
 ```
 ```xml
 <div>hello</div>
 <div>ola</div>
 ```
 ```xml
 <div t-if="someCondition"><SomeChildComponent/></div>
 ```
 ## Inline templates
 Most real applications will define their templates in a XML file, to benefit
 from the XML ecosystem, and to do some additional processing, such as translating
 them. However, in some cases, it is convenient to be able to define a template
 inline. To do so, one can use the `xml` helper function:
 ```js
 const { Component, xml } = owl;
 class MyComponent extends Component {
  static template = xml`
      <div>
          <span t-if="somecondition">text</span>
          <button t-on-click="someMethod">Click</button>
      </div>
  `;
    ...
 }
 mount(MyComponent, document.body);
 ```
 This function simply generates an unique string id, and register the template
 under that id in the internals of Owl, then return the id.
 ## Rendering svg
 Owl components can be used to generate dynamic SVG graphs:
 ```js
 class Node extends Component {
  static template = xml`
        <g>
            <circle t-att-cx="props.x" t-att-cy="props.y" r="4" fill="black"/>
            <text t-att-x="props.x - 5" t-att-y="props.y + 18"><t t-esc="props.node.label"/></text>
            <t t-set="childx" t-value="props.x + 100"/>
            <t t-set="height" t-value="props.height/(props.node.children || []).length"/>
            <t t-foreach="props.node.children || []" t-as="child">
                <t t-set="childy" t-value="props.y + child_index*height"/>
                <line t-att-x1="props.x" t-att-y1="props.y" t-att-x2="childx" t-att-y2="childy" stroke="black" />
                <Node x="childx" y="childy" node="child" height="height"/>
            </t>
        </g>
    `;
  static components = { Node };
 }
 class RootNode extends Component {
  static template = xml`
        <svg height="180">
            <Node node="graph" x="10" y="20" height="180"/>
        </svg>
    `;
  static components = { Node };
  graph = {
    label: "a",
    children: [
      { label: "b" },
      { label: "c", children: [{ label: "d" }, { label: "e" }] },
      { label: "f", children: [{ label: "g" }] },
    ],
  };
 }
 ```
 This `RootNode` component will then display a live SVG representation of the
 graph described by the `graph` property. Note that there is a recursive structure
 here: the `Node` component uses itself as a subcomponent.
 Note that since SVG needs to be handled in a specific way (its namespace needs
 to be properly set), there is a small constraint for Owl components: if an owl
 component is supposed to be a part of an svg graph, then its root node needs to
 be a `g` tag, so Owl can properly set the namespace.
@@ -0,0 +1,48 @@
 # 🦉 Translations 🦉
 take care of this and "cherry-pick" 8464a1b04e7469434f9dcb3d68a543f58cb61b8e
 If properly setup, Owl QWeb engine can translate all rendered templates. To do
 so, it needs a translate function, which takes a string and returns a string.
 For example:
 ```js
 const translations = {
  hello: "bonjour",
  yes: "oui",
  no: "non",
 };
 const translateFn = (str) => translations[str] || str;
 const qweb = new QWeb({ translateFn });
 ```
 Once setup, all rendered templates will be translated using `translateFn`:
 - each text node will be replaced with its translation,
 - each of the following attribute values will be translated as well: `title`,
  `placeholder`, `label` and `alt`,
 - translating text nodes can be disabled with the special attribute `t-translation`,
  if its value is `off`.
 So, with the above `translateFn`, the following templates:
 ```xml
 <div>hello</div>
 <div t-translation="off">hello</div>
 <div>Are you sure?</div>
 <input placeholder="hello" other="yes"/>
 ```
 will be rendered as:
 ```xml
 <div>bonjour</div>
 <div>hello</div>
 <div>Are you sure?</div>
 <input placeholder="bonjour" other="yes"/>
 ```
 Note that the translation is done during the compilation of the template, not
 when it is rendered.
@@ -6,11 +6,8 @@ functions are all available in the `owl.utils` namespace.
 ## Content
 - [`whenReady`](#whenready): executing code when DOM is ready
 - [`loadJS`](#loadjs): loading script files
 - [`loadFile`](#loadfile): loading a file (useful for templates)
- [`escape`](#escape): sanitizing strings
+- [`EventBus`](#eventbus): a simple EventBus
 - [`debounce`](#debounce): limiting rate of function calls
 - [`shallowEqual`](#shallowequal): shallow object comparison
 ## `whenReady`
@@ -19,40 +16,20 @@ not ready yet, resolved directly otherwise). If called with a callback as
 argument, it executes it as soon as the DOM ready (or directly).
 ```js
-Promise.all([loadFile("templates.xml"), owl.utils.whenReady()]).then(function ([templates]) {
+const { whenReady } = owl;
-  const qweb = new owl.QWeb({ templates });
+
-  const env = { qweb };
+await whenReady();
-  await mount(App, { env, target: document.body });
+// do something
 });
 ```
 or alternatively:
 ```js
-owl.utils.whenReady(function () {
+whenReady(function () {
-  const qweb = new owl.QWeb();
+  // do something
  const env = { qweb };
  await mount(App, { env, target: document.body });
 });
 ```
 ## `loadJS`
 `loadJS` takes a url (string) for a javascript resource, and loads it (by adding
 a script tag in the document head). It returns a promise, so the caller can
 properly reacts when it is ready. Also, it is smart: it maintains a list of urls
 previously loaded (or currently being loaded), and prevent doing twice the work.
 For example, it is useful for lazy loading external libraries:
 ```js
 class MyComponent extends owl.Component {
  willStart() {
    return owl.utils.loadJS("/static/libs/someLib.js");
  }
 }
 ```
 ## `loadFile`
 `loadFile` is a helper function to fetch a file. It simply
@@ -60,89 +37,22 @@ performs a `GET` request and returns the resulting string in a promise. The
 initial usecase for this function is to load a template file. For example:
 ```js
 const { loadFile } = owl;
 async function makeEnv() {
-  const templates = await owl.utils.loadFile("templates.xml");
+  const templates = await loadFile("templates.xml");
-  const qweb = new owl.QWeb({ templates });
+  // do something
  return { qweb };
 }
 ```
-Note that unlike `loadJS`, this function returns the content of the file as a
+## `EventBus`
 string. It does not add a `script` tag or any other side effect.
-## `escape`
+It is a simple `EventBus`, with the same API as usual DOM elements, and an
-
+additional `trigger` method to dispatch events:
 Sometimes, we need to display dynamic data (for example user-generated data) in
 the user interface. If this is done by a `QWeb` template, it is not an issue:
 ```xml
    <div><t t-esc="user.data"/></div>
 ```
 The `QWeb` engine will create a `div` node and add the content of the `user.data`
 string as a text node, so the web browser will not parse it as html. However,
 it may be a problem if this is done with some javascript code like this:
 ```js
-class BadComponent extends Component {
+const bus = new EventBus();
-  // some template with a ref to a div
+bus.addEventListener("event", () => console.log("something happened"));
  // some code ...
-  mounted() {
+bus.trigger("event"); // 'something happened' is logged
    this.divRef.el.innerHTML = this.state.value;
  }
 }
 ```
 In this case, the content of the `div` will be parsed as html, which may inject
 unwanted behaviour. To fix this, the `escape` function will simply transform a
 string into an escaped version of the same string, which will be properly displayed
 by the browser, but which will not be parsed as html (for example, `"<ok>"` is
 escaped to the string: `"&lt;ok&gt;"`). So, the bad example above can be fixed
 with the following change:
 ```js
 this.divRef.el.innerHTML = owl.utils.escape(this.state.value);
 ```
 ## `debounce`
 The `debounce` function is useful when we want to limit the number of times some
 function/action is perfomed. For example, this may be useful to prevent issue
 with people double clicking on a button.
 It takes three arguments:
 - `func` (function): this is the function that will be rate limited
 - `wait` (number): this is the number of milliseconds that we want to use to
  rate limit the function `func`
 - `immediate` (optional, boolean, default=false): if `immediate` is true, the
  function will be triggered immediately (leading edge of the interval). If false,
  the function will be triggered at the end (trailing edge).
 It returns a function. For example:
 ```js
 const debounce = owl.utils.debounce;
 window.addEventListener("mousemove", debounce(doSomething, 100));
 ```
 As this example shows, it is usualy useful for event handlers which are triggered
 very quickly, such as `scroll` or `mousemove` events.
 ## `shallowEqual`
 This function checks if two objects have the same values assigned to each keys:
 ```js
 shallowEqual({ a: 1, b: 2 }, { a: 1, b: 2 }); // true
 shallowEqual({ a: 1, b: 2 }, { a: 1, b: 3 }); // false
 ```
 However, for performance reasons, it assumes that the two objects have the same
 keys. If we are in a situation where this is not guaranteed, the following code
 will work:
 ```js
 const completeShallowEqual = (a, b) => shallowEqual(a, b) && shallowEqual(b, a);
 ```