@odoo/owl 2.2.8 → 2.2.10

package/CHANGELOG.md

@@ -0,0 +1,766 @@
+# 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.
+