概况

Odoo 网络库 (Owl) 是 Odoo为其产品构建的小型（~<20kb gzipped）UI 框架。Owl 是一个用 Typescript 编写的现代框架，以简单一致的方式从 React 和 Vue 中汲取了最好的想法。主要特点是：

• 声明式组件系统，
• 类似于 Vue 的细粒度反应系统，
• 勾子
• 组件化
• 异步渲染
• 类继承与拓展,可以更方便的拓展原有组件
• Owl 组件使用 ES6 类和 xml 模板定义，使用底层虚拟 DOM，与 hooks 完美集成，渲染是异步的。

Odoo为什么要造OWL?

在市场日新月异且用户追求不同的UI体验的今天，前端框架多种多样，像Vue、React和Angular等优秀的前端框架设计，在使用上的相关资源都很丰富，为什么odoo要自己造轮子呢？因为使用现有的前端框架并不能适用于odoo。

Odoo 非常模块化，因为odoo的集中性模块化的原因，例如Odoo的核心部分在运行之前不知道将加载/执行哪些文件或者 UI
的状态是什么，因此Odoo不能依赖标准的构建工具链。此外，Odoo 的核心部分需要非常通，Odoo
并不是真正的具有用户界面的应用程序，它是一个生成动态用户界面的应用程序，而且大多数框架都不能胜任这项任务。

在战略上：odoo为什么不适用市面上已有的框架Vue和React？因为目前的开源框架在做出更多的更新和方向变化时，更新的内容和方向与odoo本身的方向有歧义或是无意义的，且一个能控制的相适应的适配的新框架Owl会更符合odoo的需要。
框架上：odoo的模式渲染是通过继承和扩展的方式完成的，这个有他独特的优势
社区上：Vue和React的社区有很多的资源和插件，但是也是因为这些插件，在依赖相关上,odoo是不需要这些相关插件的，如vue中vuex，React中的JSX
模板上：odoo使用的xml模板语法，而目前主流的框架是都不使用xml的，强行使用会很混乱，虽然xml是有很多他诱人的地方，xpath动态修改等(小知识：excel
是可以转成xml的) 编译上： odoo是想最后编译渲染js的，且模板是存储在数据库的，所以odoo是依赖xml的xpath的

综上所述，这些大的小的问题汇聚起来，使用现有的前端框架并不能适用于odoo。

与vue和React的比较

模板差异：Vue的模板语句是需要提前写好的，React则是通过Jsx的方式通过预编译的方式去完成的，而OWL使用了XMl标签助手，可以在类中定义，也可以提前在xml中写好。

异步渲染：在React和Vue中是没有异步钩子函数的，但是在OWL中是有的： willStart（在组件开始渲染之前） willUpdateProps（在设置新道具之前） 但是这也是有风险的，及异步没有接收到返回则页面渲染是有问题的，但是也是很强大的，异步加载文件等。

组件传参：在组件传值上和数据反应上，OWL和Vue的模式一样，而不是用setState方式来改变渲染，prop的方式接受父组件传值，用eventBus方式传值，不足之处是，没有vuex的数据处理中心，这个也是OWL以后可能会加的东西吧。

组件使用开发：目前Vue和React的社区组件库都是十分强大的，而Owl因为是Odoo的前端框架，在社区的开源组件和组件开发上有很多的难点，OWl的组件需要适应odoo中模块开发的模式，上手度和组件单独性上有一定的难点，当然继承扩展也是可以实现的。

**类组件：**React正在远离类组件，React认为类对开发人员造成了一定的混乱；Odoo认为类和继承是重要的工具，具有继承性的通用组件之间共享代码是Odoo构建其Web客户端的方式，它通常是一个非常简单且合适的解决方案，最重要的是架构决策。此外，Odoo还具有类外组件的另一种特定用途，类的每个方法都为插件提供了扩展点。这可能不是一个干净的体系结构模式，但这是一个务实的决定，可以很好地服务于Odoo，有时用Monkey Patch类来增加外部行为，有点像mixin。

在线示例

更多有趣的示例可以在 **playground应用程序中找到