@odoo/owl 2.2.10 → 2.3.0

package/CHANGELOG.md

@@ -1,766 +0,0 @@
-# Changelog
-
-This document contains an overview of all changes between Owl 1.x and
-Owl 2.x, with some pointers on how to update the code.
-
-Note that some of these changes can be magically implemented (for example, by
-patching the `setup` method of `Component` to auto register all the lifecycle
-methods as hooks). This will be done for the transition period, but will be
-removed after.
-
-## From Owl 1.x to Owl 2.0
-
-All changes are documented here in no particular order.
-
-**Components**
-
-- components can now have empty content or multiple root nodes (htmlelement or text) ([details](#31-components-can-now-have-arbitrary-content))
-- breaking: component.el is removed ([details](#9-componentel-is-removed))
-- new `useEffect` hook ([doc](doc/reference/hooks.md#useeffect))
-- new `onWillDestroy`, `onWillRender` and `onRendered` hooks ([doc](doc/reference/component.md#lifecycle))
-- breaking: lifecycle methods are removed ([details](#1-component-lifecycle-methods-are-removed))
-- breaking: can no longer be mounted on detached DOM ([details](#2-components-can-no-longer-be-mounted-in-a-detached-dom-element))
-- breaking: standalone `mount` method API is simpler ([details](#4-mount-method-api-is-simpler))
-- breaking: components can no longer be instantiated and mounted by hand ([details](#5-components-can-no-longer-be-instantiated-and-mounted-by-hand))
-- breaking: components can no longer be unmounted/remounted ([details](#6-components-can-no-longer-be-unmountedremounted))
-- breaking: template name is no longer inferred from the class name ([details](#7-template-name-is-no-longer-inferred-from-the-class-name))
-- breaking: components no longer have a `shouldUpdate` method ([details](#8-components-no-longer-have-a-shouldupdate-method))
-- breaking: components can no longer be mounted with position=self ([details](#11-components-can-no-longer-be-mounted-with-positionself))
-- breaking: `render` method does not return a promise anymore ([details](#35-render-method-does-not-return-a-promise-anymore))
-- breaking: `catchError` method is replaced by `onError` hook ([details](#36-catcherror-method-is-replaced-by-onerror-hook))
-- breaking: Support for inline css (`css` tag and static `style`) has been removed ([details](#37-support-for-inline-css-css-tag-and-static-style-has-been-removed))
-- new: prop validation system can now describe that additional props are allowed (with `*`) ([doc](doc/reference/props.md#props-validation))
-- breaking: prop validation system does not allow default prop on a mandatory (not optional) prop ([doc](doc/reference/props.md#props-validation))
-- breaking: rendering a component does not necessarily render child components ([details](#40-rendering-a-component-does-not-necessarily-render-child-components))
-
-
-
-**Templates**
-
-- breaking: `t-foreach` should always have a corresponding `t-key` ([details](#20-t-foreach-should-always-have-a-corresponding-t-key))
-- breaking: `t-ref` does not work on components ([details](#29-t-ref-does-not-work-on-component))
-- breaking: `t-raw` directive has been removed (replaced by `t-out`) ([details](#38-t-raw-directive-has-been-removed-replaced-by-t-out))
-- new: add support for synthetic events ([doc](doc/reference/event_handling.md#synthetic-events))
-- breaking: style/class on components are now regular props ([details](#10-styleclass-on-components-are-now-regular-props))
-- new: components can use the `.bind` suffix to bind function props ([doc](doc/reference/props.md#binding-function-props))
-- breaking: `t-on` does not accept expressions, only functions ([details](#30-t-on-does-not-accept-expressions-only-functions))
-- new: an error is thrown if an handler defined in a `t-on-` directive is not a function (failed silently previously in some cases)
-- breaking: `t-component` no longer accepts strings ([details](#17-t-component-no-longer-accepts-strings))
-- new: the `this` variable in template expressions is now bound to the component
-
-
-**Reactivity**
-
-- finer grained reactivity: owl 2 tracks change per key/component
-- finer grained reactivity: sub components can reobserve state ([doc](doc/reference/reactivity.md))
-- new: `reactive` function: create reactive state (without being linked to a component) ([doc](doc/reference/reactivity.md#reactive))
-- new: `markRaw` function: mark an object or array so that it is ignored by the reactivity system ([doc](doc/reference/reactivity.md#markraw))
-- new: `toRaw` function: given a reactive objet, return the raw (non reactive) underlying object ([doc](doc/reference/reactivity.md#toraw))
-
-
-**Slots**
-
-- breaking: `t-set` does not define a slot any more ([details](#3-t-set-will-no-longer-work-to-define-a-slot))
-- slots capabilities have been improved ([doc](doc/reference/slots.md))
-  - params can be give to slot content (to pass information from slot owner to slot user)
-  - slots are given as a `prop` (and can be manipulated/propagated to sub components )
-  - slots can define scopes (to pass information from slot user to slot owner)
-
-
-**Portal**
-
-- Portal are now defined with `t-portal` ([details](#33-portal-are-now-defined-with-t-portal))
-- portals can now have arbitrary content (no longer restricted to one single child)
-- breaking: does no longer transfer dom events ([details](#13-portal-does-no-longer-transfer-dom-events))
-- breaking: does render as an empty text node instead of `<portal/>` ([details](#14-portal-does-render-as-an-empty-text-node-instead-of-portal))
-
-
-**Miscellaneous**
-
-- improved performance
-- much simpler code 
-- new App class to encapsulate a root Owl component (with the config for that application) ([doc](doc/reference/app.md))
-- new `useEffect` hook ([doc](doc/reference/hooks.md#useeffect))
-- breaking: `Context` is removed ([details](#15-context-is-removed))
-- breaking: `env` is now totally empty ([details](#16-env-is-now-totally-empty))
-- breaking: `env` is now frozen ([details](#28-env-is-now-frozen))
-- new hook: `useChildSubEnv` (only applies to child components) ([details](#27-usechildsubenv-only-applies-to-child-components))
-- breaking: most exports are exported at top level ([details](#18-most-exports-are-exported-at-top-level))
-- breaking: properties are no longer set as attributes ([details](#19-properties-are-no-longer-set-as-attributes))
-- breaking: `EventBus` api changed: it is now an `EventTarget` ([details](#21-eventbus-api-changed-it-is-now-an-eventtarget))
-- breaking: `Store` is removed ([details](#22-store-is-removed))
-- breaking: `Router` is removed ([details](#23-router-is-removed))
-- breaking: transition system is removed ([details](#24-transition-system-is-removed))
-- breaking: no more global components or templates ([details](#25-no-more-global-components-or-templates))
-- breaking: `AsyncRoot` utility component is removed ([details](#26-asyncroot-utility-component-is-removed))
-- breaking: `renderToString` function on qweb has been removed ([details](#32-rendertostring-on-qweb-has-been-removed))
-- breaking: `debounce` utility function has been removed ([details](#34-debounce-utility-function-has-been-removed))
-- breaking: `browser` object has been removed ([details](#39-browser-object-has-been-removed))
-
-## Details/Rationale/Migration
-
-All changes are listed in no particular order.
-
-### 1. component lifecycle methods are removed
-
-There was two ways to define hooks: the component methods (`willStart`, `mounted`, ...) and the hooks (`onWillStart`, `onMounted`, ...). In Owl 2, the component methods have been removed.
-
-Rationale: it makes the implementation simpler and slightly faster. Hooks are more composable
-than component methods. It enforces a single entry point to check all the useful lifecycle
-calls (instead of it being scattered in the component definition). It feels more "modern".
-
-Migration: lifecycle methods should be defined in the `setup`:
-
-```js
-class MyComponent extends Component {
-  mounted() {
-    // do something
-  }
-}
-```
-should become:
-```js
-class MyComponent extends Component {
-  setup() {
-    onMounted(() => {
-      // do something
-    });
-  }
-}
-```
-
-Documentation: [Component Lifecycle](doc/reference/component.md#lifecycle)
-
-### 2. components can no longer be mounted in a detached dom element
-
-Nor document fragment.
-
-Rationale: it is actually very difficult to do it: this implies that a component
-can be mounted more than once, that we need to check every time different status,
-that some elements is in the dom, and was a cause for bugs. Also, we don't use it
-in practice. Removing this means that we have a much simpler mental model of what
-happens.
-
-Migration: well, not really easy. The code needs to be refactored in a different way.
-
-
-### 3. **`t-set` will no longer work to define a slot**
-
-The `t-set` directive cannot define a slot anymore. Only the `t-set-slot` directive
-can do it.
-
-Rationale: it was left for compatibility reason, but was deprecated anyway.
-
-Migration: `t-set` should be changed to `t-set-slot` (when defining a slot)
-
-Example:
-
-```xml
-<SideBar><t t-set="content">content</t></SideBar>
-```
-should become:
-```xml
-<SideBar><t t-set-slot="content">content</t></SideBar>
-```
-
-### 4. `mount` method API is simpler
-
-Before, the `mount` method was used like this:
-
-```js
-await mount(Root, { target: document.body });
-```
-
-It is now simpler and takes the root component and a target argument:
-
-```js
-await mount(Root, document.body);
-```
-
-Rationale: the `mount` method is only useful anyway for small toy examples,
-because real applications will need to configure the templates, the translations,
-and other stuff. All complex usecases need to go through the new `App` class,
-that encapsulates the root of an owl application.
-
-Documentation: [Mounting a component](doc/reference/app.md#mount-helper)
-
-### 5. components can no longer be instantiated and mounted by hand
-
-In Owl 1, it was possible to instantiate a component by hand:
-
-```js
-const root = new Root();
-await root.mount(document.body);
-```
-
-Now, it is no longer possible. All component instantiations should be done by
-the owl framework itself.
-
-Rationale: the `mount` method does not make sense for all non root components.
-Also, the fact that it was possible for a component to be sometimes root,
-sometimes a child made for a weird constructor signature. This changes makes it
-simpler.
-
-Migration: all code doing that should use either the `mount` method (if the use
-case is simple enough, or the `App` class):
-
-```js
-const app = new App(Root);
-app.configure({ templates: ..., ...});
-await app.mount(document.body);
-```
-
-### 6. components can no longer be unmounted/remounted
-
-Rationale: this is a very difficult feature to implement (it adds a lot of possible
-state transitions), compared to its benefit.
-
-Migration: all code using it should find a way to export and reimport the state
-
-### 7. template name is no longer inferred from the class name
-
-Before, it was possible to define a component without specifying its template:
-
-```js
-class Blabla extends Component {
-    // no static template here!
-}
-```
-with the `Blabla` template. It also worked with subclasses. But then, this means
-that the code had to look up all the super classes names to find the correct
-template.
-
-Rationale: in practice, it is not really useful, since all templates are usually
-namespaced: `web.SomeComponent` anyway. All the trouble to do that was just not
-worth it.
-
-Migration: simply explicitely defines the template key everytime:
-
-```js
-class Blabla extends Component {}
-Blabla.template = "Blabla";
-```
-
-### 8. components no longer have a `shouldUpdate` method
-
-Rationale: `shouldUpdate` is a dangerous method to use, that may cause a lot of
-issues. Vue does not have such a mechanism (see https://github.com/vuejs/vue/issues/4255),
-because the reactivity system in Vue is smart enough to only rerender the minimal
-subset of components that is subscribed to a piece of state. Now, Owl 2 features
-a much more powerful reactivity system, so the same rationale applies: in a way,
-it's like each Owl 2 component has a `shouldUpdate` method that precisely tracks
-every value used by the component.
-
-Migration code: remove the `shouldUpdate` methods, and it should work as well
-as before.
-
-### 9. component.el is removed
-
-This comes from the fact that Owl 2 supports fragments (arbitrary content).
-
-Migration: if one need a reference to the root htmlelement of a template, it is
-suggested to simply add a `ref` on it, and access the reference as needed.
-
-Documentation: [Refs](doc/reference/refs.md)
-
-### 10. style/class on components are now regular props
-
-Before, it was possible to do this in a template:
-
-```xml
-<Child style="..." class="..."/>
-```
-(or with `t-att-style` and `t-att-class`). This does no longer work, as they are
-now considered normal props.
-
-Rationale: with the move to fragments, the semantics of where the style/class
-attribute should be set is unclear. Also, it is actually very hard to implement
-properly, in particular with higher order components. And another issue is that
-it (slightly) breaks the encapsulation of behaviour from the `Child` component
-perspective.
-
-Migration: each component that wishes to be customized should explicitely add
-the `class` and `style` attributes in its template. Also, the parent component
-should be aware that since we are talking about props, it should be a javascript expression:
-
-In parent:
-
-```xml
-<Child class="'o_my_god'"/>
-```
-and in child:
-
-```xml
-    <div t-att-class="props.class">
-        ...
-    </div>
-```
-
-### 11. components can no longer be mounted with position=self
-
-Rationale: this is due to the implementation of owl 2 virtual dom. The hack
-necessary to support position=self does not work. This position also is not
-compatible with the fact that a component can have a root `<div>` then later,
-change it to something else, or even a text node.
-
-Migration: no real way to do the same. Owl application needs to be appended or
-prepended in something, maybe a `div`. Remember that you the root component
-can have multiple roots
-
-Documentation:
-- [Fragments](doc/reference/templates.md#fragments)
-- [Mounting a component](doc/reference/app.md#mount-helper)
-
-
-### 13. Portal does no longer transfer DOM events
-
-In Owl 1, a Portal component would listen to events emitted on its portalled
-child, and redispatch them on itself. It no longer works.
-
-Rationale: Portal now supports an arbitrary content (so, more than one child,
-and potentially no html element), so it is already unclear what it should listen
-to. Also, redispatching events was an hack. And this changes allows the portal
-to render itself as a text node, which is nice. This is also in line with the
-fact that modern Owl moves toward using callback instead of `t-on` for communication.
-
-Migration: use callback if possible to communicate. Otherwise, use a sub env.
-
-### 14. Portal does render as an empty text node instead of `<portal/>`
-
-That is pretty nice. No real migration needed.
-
-### 15. Context is removed
-
-Context was an abstraction in Owl that was used to define some reactive state
-and to let some components subscribe to it, then only them would be rerendered
-if the context was updated. This has been removed.
-
-Rationale: first, the Context api and code was kind of awkward, which is a sign
-that the abstraction is not well thought. But the good news is that it is actually
-completely replaced by the new reactivity system, which is even more powerful,
-since it can tracks changes key by key.
-
-Migration: replace all uses of Context with the new reactivity system.
-
-```js
-// somewhere, maybe in a service, or in the global env
-const context = observe({some: "state"})
-
-// in a component that would previously get a reference to the context:
-
-setup() {
-    this.context = useState(context);
-    // now the component is subscribed to the context and will react to any
-    // change for any key read by the component, and only those changes
-}
-```
-
-### 16. `env` is now totally empty
-
-In Owl 1, the `env` object had to contain a QWeb instance. This was the way
-components would get a reference to their template function. It no longer works
-that way: the `env` object is now totally empty (from the perspective of Owl).
-It is now a user space concept, useful for the application.
-
-Rationale: first, there is no longer a QWeb class. Also, this changes simplifies
-the way components works internally.
-
-Migration: there is no proper way to get an equivalent. The closest is to get
-a reference to the root App using `this.__owl__.app`. If you need to do this,
-let us know. If this is a legitimate usecase, we may add a `useApp` hook.
-
-Documentation: [Environment](doc/reference/environment.md)
-
-### 17. `t-component` no longer accepts strings
-
-In owl 1, we could write this:
-
-```xml
-<t t-component="Coucou"/>
-```
-
-This meant that Owl would look for the component class like this: `components["Coucou"]`,
-so, essentially equivalent to `<Coucou/>`. In Owl 2, the `t-component` directive
-is assumed to be an expression evaluating to a component class:
-
-```js
-class Parent extends Component {
-  static template = xml`<t t-component="Child"/>`;
-  Child = Child;
-}
-```
-
-Rationale: it simply seems more consistent with the way directive works. Also,
-the implementation is slightly simpler.
-
-Migration: simply using `constructor.components.Coucou` instead of `Coucou` will
-do the trick.
-
-Documentation: [Component](doc/reference/component.md#dynamic-sub-components)
-
-### 18. most exports are exported at top level
-
-Most exports are flattened: for ex, `onMounted` is in owl, not in `owl.hooks`.
-
-Rationale: this makes it easier to work with, instead of importing stuff from 
-`owl`, then `owl.hooks` and `owl.tags` for example.
-
-Migration: all import code simply need to be slightly adapted.
-
-### 19. Properties are no longer set as attributes
-
-Formerly, html properties `<input type="checkbox" t-att-checked="blah"/>` were
-set as property and as attribute, so, they would be visible in the DOM:
-`<input type="checkbox" checked="blah"/>`. Now, they are treated as property only:
-`<input type="checkbox"/>`.
-
-Rationale: this is actually simple to do, is faster, and makes more sense to me.
-
-### 20. `t-foreach` should always have a corresponding `t-key`
-
-It was possible in Owl 1 to write a `t-foreach` without a `t-key`. In that case,
-the index was used as key.  Since it was clearly a possible bug, Owl 1 had a
-warning in some cases, when it could detect that there was definitely not a `t-key`.
-However, this was imperfect, and in some cases no warning was displayed. In Owl 2,
-the tag with a `t-foreach` has to have a corresponding `t-key`.
-
-Rationale: this makes it easier to avoid bugs.
-
-Migration: simply move the `t-key` to the tag with the `t-foreach`. If this is
-a situation where there is really not a need for a `t-key`, you can still add
-it with the `_index` suffix:
-
-```xml
-<div t-foreach="items" t-as="item" t-key="item_index">
-  ...
-</div>
-```
-
-### 21. `EventBus` api changed: it is now an `EventTarget`
-
-In Owl 1, the `EventBus` class was done manually, with a custom API. In Owl 2,
-it simply extends `EventTarget` (the native Dom class), so its implementation
-is basically only 5 lines long. This means that it has now the usual DOM interface:
-
-```js
-bus.addEventListener('event-name', callback);
-```
-
-Rationale: it makes it easier to have just one interface to remember, it makes
-the code simpler
-
-Migration: most bus methods need to be adapted. So, `bus.on("event-type", owner, (info) => {...})` has to be
-rewritten like this: `bus.addEventListener("event-type", (({detail: info}) => {...}).bind(owner))`.
-
-Do not forget to similarly replace `bus.off(...)` by `bus.removeEventListener(...)`
-
-Documentation: [EventBus](doc/reference/utils.md#eventbus)
-
-### 22. `Store` is removed
-
-The Store system had been abandoned in owl 2.
-
-Rationale: first, it was complicated to maintain. Second, it was not really
-used in Odoo. Finally, the new reactivity system seems to be a pretty good basis
-to write a store, and it should not take much work. Also, this can be done in
-user space (so, not necessarily at the framework level). Another point is that
-the store API was invented before the hooks, then was still a little awkward.
-
-Migration:
-- rewrite the code not to use a store
-- probably use the reactivity system instead and build a store class and a few
-  hooks on top of it.
-
-### 23. `Router` is removed
-
-Rationale: Router was not used that much, and it felt like it did not fit in Owl 2.
-Its API needs to be reworked, and we are not confident that it is a good
-experience to use it. Also, it can be done in userspace (it does not need specific
-integration at the framework level)
-
-Migration: reimport all missing piece from the code in Owl 1.
-
-### 24. transition system is removed
-
-Rationale: this was a high ratio cost/value, with a lot of potential for bugs.
-We feel like there should be a way to reimplement in userspace the simple cases.
-
-Maybe something like: add a `t-ref` in the template, and define a hook `useFadeOut`
-that takes the ref, and add a fadeout class at initial render, then in mounted,
-wait for a micro tick and remove it.
-
-Migration: try to reimplement it manually. 
-
-### 25. no more global components or templates
-
-It was possible in Owl 1 to register globally a component or a template. This is
-no longer the case in Owl 2.
-
-Rationale: first, this was a tradeoff: ease of use was gained, but at the cost
-of a higher complexity. Users had to know that there was a magic mechanism. Also,
-it was not used much in practice, and the cost of having to import manually components
-is low.  Finally, this can be mostly done in user space (for example, by subclassing
-`Component`).
-
-Migration: import manually all required global components, or find a way to organize
-the code to do it.
-
-### 26. `AsyncRoot` utility component is removed
-
-Rationale: it was difficult to understand, never used, and not really useful.
-It seems better to control the asynchrony of an application by simply controlling
-how/when the state is updated, and how each component is loading/updating itself.
-
-Migration: remove the `AsyncRoot` component, then possibly, reorganize the code
-to fetch data in a higher order component, and using a `t-if/t-else` to display
-either a fallback when the data is not ready, or the actual component with data
-as props.  If there is no escape, and `AsyncRoot` is needed, please reach out to
-us so we can study this usecase.
-
-### 27. `useChildSubEnv` (only applies to child components)
-
-In Owl, a call to `useSubEnv` would define a new environment for the children
-AND the component. It is very useful, but in some cases, one only need to update
-the children component environment. This can now be done with a new hook:
-[`useChildSubEnv`](doc/reference/hooks.md#usesubenv-and-usechildsubenv)
-
-### 28. `env` is now frozen
-
-In Owl 2, the `env` object is frozen. It can no longer be modified (structurally)
-arbitrarily. 
-
-Rationale: it seems like the `env` object purpose is to have a global channel of
-communication between components. It is however scary if anyone can add something
-to it.  The usual use case is to add something to the environment for some child
-components. This use case still works with `useSubEnv`.
-
-Migration: use `useSubEnv` instead of writing directly to the env.  Also, note
-that the environment given to the App can initially contain anything.
-
-Documentation: [Environment](doc/reference/environment.md)
-
-### 29. `t-ref` does not work on component
-
-Before, `t-ref` could be used to get a reference to a child component. It no
-longer works.
-
-Rationale: the possibility of having a ref to a child component breaks the
-encapsulation provided by Owl components: a child component now has a private
-and a public interface.  Another issue is that it may be unclear when the ref
-should be set: is the component active on setup, or on mounted? Also, it is
-kind of awkward to implement.
-
-Migration: the `env` and `props` should provide a communication channel wide enough:
-the sub component can expose its public API by calling a callback at the proper
-timing, or by triggering an event.
-
-### 30. `t-on` does not accept expressions, only functions
-
-In Owl 1, it was possible to define simple expressions inline, in a template:
-
-```xml
-<button t-on-click="state.value = state.value + 1">blabla</button>
-<button t-on-click="someFunction(someVar)">blabla</button>
-```
-
-This does not work anymore. Now, the `t-on` directive assumes that what it get is
-a function.
-
-Rationale: the fact that owl 1 had to support expressions meant that it was not
-possible to properly inject the event in general. With this restriction, Owl 2
-can support more general use cases. Also, the examples above can simply be
-wrapped in a lambda function. 
-
-Migration: use lambda functions. For example, the two examples above can be
-adapted like this:
-
-```xml
-<button t-on-click="() => state.value = state.value + 1">blabla</button>
-<button t-on-click="() => this.someFunction(someVar)">blabla</button>
-```
-
-Documentation: [Event Handling](doc/reference/event_handling.md)
-
-### 31. components can now have arbitrary content
-
-Before Owl 2, components had to limit themselves to one single htmlelement as
-root. Now, the content is arbitrary: it can be empty, or multiple html elements.
-So, the following template works for components:
-
-```xml
-  <div>1</div>
-  <div>2</div>
-  hello
-```
-
-Documentation: [Fragments](doc/reference/templates.md#fragments)
-
-### 32. `renderToString` on QWeb has been removed
-
-Rationale: the `renderToString` function was a qweb method, which made sense because
-the qweb instance knew all templates. But now, the closest analogy is the `App`
-class, but it is not as convenient, since the `app` instance is no longer visible
-to components (while before, `qweb` was in the environment).
-
-Also, this can easily be done in userspace, by mounting a component in a div.  For example:
-
-```js
-export async function renderToString(template, context) {
-  class C extends Component {
-    static template = template;
-    setup () {
-        Object.assign(this, context);
-    }
-  }
-  const div = document.createElement('div');
-  document.body.appendChild(div);
-  const app = new App(C);
-  await app.mount(div);
-  const result = div.innerHTML;
-  app.destroy();
-  div.remove();
-  return result;
-}
-```
-
-The function above works for most cases, but is asynchronous.  An alternative
-function could look like this:
-
-```js
-const { App, blockDom } = owl;
-const app = new App(Component); // act as a template repository
-
-function renderToString(template, context = {}) {
-  app.addTemplate(template, template, { allowDuplicate: true });
-  const templateFn = app.getTemplate(template);
-  const bdom = templateFn(context, {});
-  const div = document.createElement('div')
-  blockDom.mount(bdom, div);
-  return div.innerHTML;
-}
-```
-
-This is a synchronous function, so it will not work with components, but it should
-be useful for most simple templates.
-
-Also note that these two examples do not translate their templates. To do that,
-they need to be modified to pass the proper translate function to the `App`
-configuration.
-
-### 33. Portal are now defined with `t-portal`
-
-Before Owl 2, one could use the `Portal` component by importing it and using it.
-Now, it is no longer available. Instead, we can simply use the `t-portal` directive:
-
-```xml
-<div>
-  some content
-  <span t-portal="'body'">
-    portalled content
-  </span>
-<div>
-```
-
-Rationale: it makes it slightly simpler to use (just need the directive, instead
-of having to import and use a sub component), it makes the implementation slightly
-simpler as well. Also, it prevents subclassing the Portal component, which could
-be dangerous, since it is really doing weird stuff under the hood, and could
-easily be broken inadvertendly.
-
-### 34. `debounce` utility function has been removed
-
-Rationale: it did not really help that much, is available as utility function
-elsewhere, so, we decided to have a smaller footprint by focusing Owl on what
-it does best.
-
-### 35. `render` method does not return a promise anymore
-
-Rationale: using the `render` method directly and waiting for it to complete
-was slightly un-declarative. Also, it can be done using the lifecycle hooks
-any way.
-
-Migration: if necessary, one can use the lifecycle hooks to execute code after
-the next mounted/patched operation.
-
-### 36. `catchError` method is replaced by `onError` hook
-
-The `catchError` method was used to provide a way to components to handle errors
-occurring during the component lifecycle. This has been replaced by a `onError`
-hook, with a similar API.
-
-Rationale: `catchError` felt a little big awkward, when most of the way we
-interact with componentss is via hooks.  Using hooks felt more natural and
-consistent.
-
-Migration: mostly replace all `catchError` methods by `onError` hooks in the
-`setup` method.
-
-Documentation: [Error Handling](doc/reference/error_handling.md)
-
-
-## 37. Support for inline css (`css` tag and static `style`) has been removed
-
-Rationale: Owl tries to focus on what it does best, and supporting inline css
-was not a priority.  It used to support some simplified scss language, but it
-was feared that it would cause more trouble than it was worth. Also, it seems
-like it can be done in userspace.
-
-Migration: it seems possible to implement an equivalent solution using hooks. A
-simple implementation could look like this:
-
-```js
-let cache = {};
-
-function useStyle(css) {
-  if (!css in cache) {
-    const sheet = document.createElement("style");
-    sheet.innerHTML = css;
-    cache[css] = sheet;
-    document.head.appendChild(sheet);
-  }
-}
-```
-
-## 38. `t-raw` directive has been removed (replaced by `t-out`)
-
-To match the Odoo qweb server implementation, Owl does no longer implement `t-raw`.
-It is replaced by the `t-out` directive, which is safer: it requires the data
-to be marked explicitely as markup if it is to be inserted without escaping.
-Otherwise, it will be escaped (just like `t-esc`).
-
-Migration: replace all `t-raw` uses by `t-out`, and uses the `markup` function
-to mark all the js values.
-
-Documentation: [Outputting data](doc/reference/templates.md#outputting-data)
-
-## 39. `browser` object has been removed
-
-Rationale: the `browser` object caused more trouble than it was worth. Also, it
-seems like this should be done in user space, not at the framework level.  
-
-Migration: code should just be adapted to either use another browser object,
-or to use native browser function (and then, just mock them directly).
-
-## 40. Rendering a component does not necessarily render child components
-
-Before, if one had the following component tree:
-
-```mermaid
-  graph TD;
-      A-->B;
-      A-->C;
-```
-
-when `A` would render, it would also render `B` and `C`. Now, in Owl 2, it will 
-(shallow) compare the before and after props, and `B` or `C` will only be rerendered
-if their props have changed.
-
-Now, the question is what happens if the props have changed, but in a deeper way?
-In that case, Owl will know, because each props are now reactive. So, if some
-inner value read by `B` was changed, then only `B` will be updated.
-
-Rationale: This was just not possible in Owl 1, but it now possible. This is
-due to the rewriteof the underlying rendering engine and the reactivity
-system. The goal is to have a big performance boost in large screen with many
-components: now Owl only rerender what is strictly useful.
-