If you tried learning Odoo client-side development in the past year, you probably hit one of two problems. Either you followed the web framework tutorial and wrote code using useStateand Owl 2 template syntax that no longer works in production, or you found the Owl playground exercises and couldn’t figure out how they connected to the web framework tutorial that was supposed to come first. Odoo just fixed both problems by throwing everything out and starting over.
One Tutorial Where There Used to Be Two
The old setup split client-side learning into a “Discover the Web Framework” tutorial and a separate set of Owl playground exercises. In theory, you did one then the other. In practice, neither tutorial referenced the other well enough for the connection to be obvious, and both had accumulated enough Owl 2 syntax to mislead anyone who copy-pasted code into an Odoo 20 module.
The new client_framework_101 guide merges both into a single, two-part tutorial that was rewritten from scratch using material from the 2026 JavaScript masterclass. Part one covers Owl components directly: signals-based reactivity, lifecycle hooks likeonWillStart and onMounted, and hands-on exercises that run in the Owl playground. Part two builds a real dashboard — the awesome_dashboardaddon — that uses everything from part one in context.
Signals Replace useState: The Biggest Breaking Change
The most significant API change in Owl 3 is the move fromuseStateto signals-based reactivity. If you’ve used SolidJS or Preact Signals, the mental model is familiar: reactive state is declared with $reactive and changes propagate automatically without the hook-based indirection that useStaterequired. Components re-render when their reactive dependencies change, and only when they change.
For Odoo developers, this means less boilerplate and fewer subtle bugs. The old pattern of forgetting to wrap state in useStateand getting a component that updated internally but never re-rendered — that entire category of mistake is gone. Reactive state is reactive by default, not by ceremony.
From Counter to Dashboard: The Learning Path
The tutorial’s progression is well-designed. Part one starts with a counter component — the “hello world” of reactive frameworks — and incrementally introduces templates, event handlers, props, and lifecycle hooks. Each concept gets an exercise in the Owl playground, which means you can experiment without setting up a full Odoo development environment.
Part two ramps up dramatically. You build an awesome_dashboardaddon that pulls in the Layout component, implements the plugin architecture with usePlugin and services.add, makes RPC calls with caching, renders a Chart.js pie chart through a custom useChart hook, creates a generic item registry with validation, builds a settings dialog backed by local storage, and finishes with lazy-loading via LazyComponent and asset bundles.
That’s a serious amount of ground to cover, and it mirrors the actual patterns you’ll encounter in Odoo’s production codebase. The dashboard isn’t a toy example; it exercises the same APIs and architectural patterns that the core web client uses.
Why the Rewrite Matters Beyond Documentation
Developer tutorials are often the last thing to get updated when a framework ships a major version. They’re not user-facing, they don’t show up in feature comparison charts, and the people qualified to write them are usually busy building the next release. The result is what Odoo had until this week: tutorials that teach patterns the framework no longer uses.
By grounding the rewrite in actual masterclass material rather than just updating code samples, Odoo is signaling that the transition to Owl 3 is complete enough to teach. That matters for the ecosystem. Third-party module developers, integration partners, and companies with in-house Odoo teams now have a reliable starting point that reflects how the framework actually works in version 20, not how it worked two versions ago with a few deprecation warnings sprinkled on top.