Géry Debongnie bb64e87634 [FIX] store: properly render, even if shouldupdate is implemented
Before this commit, an unwanted behaviour happened when using components
with shouldUpdate implemented, and store/state.

The actual problem is the following: the sub component is using a store,
and shouldupdate.  Whenever the component is rendered, it checks if there is an incoming
rendering from the context.  If that is the case, it skips the
rendering, because we actually only want to be rendered by the store
rendering (otherwise, we may run into issue with inconsistent data (more
recent data from the context, older data in the component).

However, if shouldUpdate is implemented, then the rendering coming from
the context simply does not arrive.

To fix this, we tried to just force these renderings to go through all children,
regardless of their shouldUpdate status. This actually works, but then
shouldUpdate is ignored, which is an issue in Odoo discuss.

Then, after discussing this situation, we noticed that the context/store
system is actually unsafe: the protection given by the check mentioned
above is in fact fundamentally insufficient: there are other perfectly
valid situations where a rendering can be triggered on the component,
which will bypass the check (for example, an explicit call to
this.render() or a rendering initiated by some parent component) and
cause a crash if the component is not properly defensively written.

Therefore, it is currently mandatory for all components using
context/store to be aware of that, and to protect themselves against
such situations. So, in that regard, the check is not really a
protection, it just helps hiding an unsafe situation anyway and we
decided to remove it.

Note that this is a potentially breaking change: components using a
store and some local state will now be rendered twice in some cases...

closes #799
2020-12-14 13:19:36 +01:00
2020-10-30 15:31:03 +01:00
2019-03-18 14:26:33 +01:00
2019-10-01 20:44:39 +02:00
2019-05-03 16:19:33 +02:00
2020-11-20 11:02:19 +01:00
2020-11-20 11:02:19 +01:00
2020-11-20 11:02:19 +01:00

🦉 OWL Framework 🦉

Class based components with hooks, reactive state and concurrent mode

Project Overview

The Odoo Web Library (OWL) is a smallish (~<20kb gzipped) UI framework intended to be the basis for the Odoo Web Client. Owl is a modern 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,
  • concurrent mode by default,
  • a store and a frontend router

Owl components are defined with ES6 classes, they use QWeb templates, an underlying virtual DOM, integrates beautifully with hooks, and the rendering is asynchronous.

Try it online! An online playground is available at https://odoo.github.io/owl/playground to let you experiment with the Owl framework. There are some code examples to showcase some interesting features.

Owl is currently stable. Possible future changes are explained in the roadmap.

Why Owl?

Why did Odoo decide to make Yet Another Framework? This is really a question that deserves a long answer. But in short, we believe that while the current state of the art frameworks are excellent, they are not optimized for our use case, and there is still room for something else.

If you are interested in a comparison with React or Vue, you will find some more additional information here.

Example

Here is a short example to illustrate interactive components:

const { Component, useState, mount } = owl;
const { xml } = owl.tags;

class Counter extends Component {
  static template = xml`
    <button t-on-click="state.value++">
      Click Me! [<t t-esc="state.value"/>]
    </button>`;

  state = useState({ value: 0 });
}

class App extends Component {
  static template = xml`
    <div>
      <span>Hello Owl</span>
      <Counter />
    </div>`;

  static components = { Counter };
}

mount(App, { target: document.body });

Note that the counter component is made reactive with the useState hook. Also, all examples here uses the xml helper to define inline templates. But this is not mandatory, many applications will load templates separately.

More interesting examples can be found on the playground application.

Design Principles

OWL is designed to be used in highly dynamic applications where changing requirements are common and code needs to be maintained by large teams.

  • XML based: templates are based on the XML format, which allows interesting applications. For example, they could be stored in a database and modified dynamically with xpaths.
  • templates compilation in the browser: this may not be a good fit for all applications, but if you need to generate dynamically user interfaces in the browser, this is very powerful. For example, a generic form view component could generate a specific form user interface for each various models, from a XML view.
  • no toolchain required: this is extremely useful for some applications, if, for various reasons (security/deployment/dynamic modules/specific assets tools), it is not ok to use standard web tools based on npm.

Owl is not designed to be fast nor small (even though it is quite good on those two topics). It is a no nonsense framework to build applications. There is only one way to define components (with classes). There is no black magic. It just works.

Documentation

A complete documentation for Owl can be found here:

Some of the most important pages are:

Installing Owl

Owl is available on npm and can be installed with the following command:

npm install @odoo/owl

If you want to use a simple <script> tag, the last release can be downloaded here:

License

OWL is LGPL licensed.

S
Description
OWL: A web framework for structured, dynamic and maintainable applications
Readme LGPL-3.0 27 MiB
Languages
TypeScript 87.3%
JavaScript 12.1%
CSS 0.5%
Python 0.1%