odoo / owl

OWL: A web framework for structured, dynamic and maintainable applications
https://odoo.github.io/owl/
Other
1.14k stars 344 forks source link

create a `owl-extra` library, with basic useful features #1567

Open ged-odoo opened 10 months ago

ged-odoo commented 10 months ago

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:

ged-odoo commented 10 months ago

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

ged-odoo commented 10 months ago

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

aab-odoo commented 10 months ago

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.