[DOC] reorganize and update documentation to owl 2

doc/miscellaneous/architecture.md

@@ -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).

doc/miscellaneous/comparison.md

@@ -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 {

doc/miscellaneous/rendering.md

@@ -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).

doc/miscellaneous/vdom.md

@@ -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).