create a owl-extra library, with basic useful features

[ged-odoo]

Motivation

Owl has been designed to be minimalist. The point is that Owl does not have an opinion on what the best architecture is, and as such, it does not provide any (direct) support for features such as routing, complex state management (store and such), or even a basic component library. Owl 1.0 had a router and a store, but they were removed for owl 2.0, because it seems easy to do it in userspace, especially with the new reactive primitive.

However, at some point, if owl is to be taken seriously, it is useful to have a basic suite of well designed primitives. Also, it is even a need right now: for example the spreadsheet library has to reimplement a few features such as the dropdown components, which implies managing overlays, positioning and other complex code.

Draft Specification

How it could work?

Ideally, it should probably be in another repository (@odoo/owl-extra), that Odoo would maintain. However, it may be difficult to convince some people, so a fallback could be a new build output (owl-extra-2.X.Y.js) ? The question is how to integrate it properly in odoo, with autocompletion and types and such...

import { extras } from "@odoo/owl"; // not so good. probably not possible to do it in a typesafe way
import { something } from "@odoo/owl-extras" // would be nice

Content of owl extras

For now, here is what I would like to see:

• a basic service system (probably synchronous?), as I believe it proved in the previous years that it is a robust abstraction that makes sense, and is quite easy to understand/work with
• a overlay service
• add support for transparently create and manipulate the overlay container while mounting an application
• a dropdown component
• a dialog component. (and a dialog service I guess?)
• maybe a popover service/API?

[ged-odoo]

maybe @aab-odoo @sdegueldre @VincentSchippefilt would like to comment

[ged-odoo]

so yeah, I know that after trying to remove services entirely, I am now trying to move them into owl...

[aab-odoo]

I guess it would make sense. I know spreadsheet have their own implementation of stuff we already implemented in /web.

A few minor reactions on details though. I'm not in favor of having to import stuff from owl and from owl-extras. I think people would never know where is located the feature they want. Maybe a single file, and a build config allowing to pick optional features?

And about the synchronous (?) service system: not sure it should be different from the one we use in web for several reasons. If we need an asynchronous system, others might probably need it as well. Also, having a synchronous system in owl and an asynchronous one in web/ would probably mean that we have to rewrite the startService function, which is obviously not ideal. I don't think we want to use an altered version of owl, people could get confused.