[DOC] add information about reactivity

CHANGELOG.md

@@ -31,6 +31,7 @@ All changes are documented here in no particular order.
 - 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))
 
 
 
@@ -798,4 +799,28 @@ 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).
+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.
+

doc/reference/component.md

@@ -68,12 +68,16 @@ The `Component` class has a very small API.
   component will go through the following lifecycle methods: `willUpdateProps`,
   `willPatch` and `patched`.
 
-* **`render()`**: calling this method directly will cause a rerender. Note
+* **`render(deep[=false])`**: calling this method directly will cause a rerender. Note
   that with the reactivity system, this should be rare to have to do it manually.
   Also, the rendering operation is asynchronous, so the DOM will only be updated
   slightly later (at the next animation frame, if no component delays the
   rendering)
 
+  By default, the render initiated by this method will stop at each child
+  component if their props are (shallow) equal. To force a render to update
+  all child components, one can use the optional `deep` argument.
+
 ## Static Properties
 
 - **`template (string)`**: this is the name of the template that

doc/reference/reactivity.md

@@ -25,6 +25,11 @@ To solve this issue, Owl provides two reactivity primitives:
 
 Most of the time, the `useState` hook is the best solution.
 
+Since version 2.0, Owl applies the fine grained reactivity at the component
+level: props are automatically turned into reactive object, so Owl can track
+which part of these props are consumed by each component, and is therefore able
+to only rerender the impacted components.
+
 ## `useState`
 
 Let us start by an example of how `useState` could be used: