OWL 3: o que muda no framework front-end do Odoo (signals, plugins e o fim do env)

A Odoo publicou o documento de design do OWL 3. Ainda é trabalho em andamento, o próprio texto avisa que o design pode evoluir. Mas já dá pra ver o tamanho da coisa: é a maior mudança no framework desde o OWL 2, e quem mantém módulo customizado de Odoo vai sentir.

Eu leio documento de design de framework do mesmo jeito que leio migração de versão do Odoo: não pra correr atrás hoje, mas pra saber onde o chão vai estar daqui a dois anos. Esse aqui merece a leitura.

Contexto: por que o Odoo tem um framework próprio

Todo o front-end do Odoo (backoffice, PDV, site) roda em cima do OWL, um framework de componentes criado pela própria Odoo, inspirado em React e Vue, mas desenhado para as necessidades do ERP: templates XML definidos no servidor, herança de views, componentes que precisam conviver com código legado. O OWL 2 está aí desde o Odoo 16. Qualquer widget custom, qualquer tela customizada que sua consultoria fez, é OWL.

Por isso um redesign do OWL não é assunto só de quem desenvolve framework. É assunto de quem tem Odoo rodando com customização de interface.

O motivo da reescrita: a reatividade por proxies cobrou a conta

O OWL 2 usa reatividade baseada em proxies do JavaScript: você mexe num objeto useState/reactive e o framework descobre sozinho o que re-renderizar. Funciona bem em tela pequena. Em base de código grande (e a da Odoo é enorme), o próprio documento admite os problemas:

• bugs sutis e difíceis de diagnosticar em fluxos complexos de atualização;
• valores computados ineficientes, que geraram uma coleção de gambiarras internas: caches escritos à mão, getters, onWillRender usado pra pré-computar valor;
• pouca ajuda do IDE: props e env sem autocompletar, exigindo .d.ts manual;
• falta de padrão arquitetural, cada equipe estruturando o front de um jeito.

Se você já depurou uma tela OWL custom que re-renderizava sem motivo aparente, sabe exatamente de que classe de bug o documento está falando.

Signals: a mudança central

O OWL 3 troca os proxies por um sistema de signals, computed e effects. useState e reactive deixam de existir; entram signal(), computed() e proxy():

const count = signal(0);
count();        // le o valor
count.set(4);   // atualiza

const s1 = signal(3);
const d1 = computed(() => 2 * s1());  // recalcula so quando s1 muda, e de forma lazy

A diferença conceitual: com signals, a dependência fica explícita no momento da leitura. O framework não precisa mais adivinhar, via proxy, quem depende de quê. O documento resume: isso “melhora a previsibilidade e reduz atualizações surpreendentes”.

Detalhe importante: signals não pertencem a um componente. São valores reativos independentes, que podem viver num plugin, num módulo, onde fizer sentido. Para coleções, há wrappers dedicados (signal.Array, signal.Object, signal.Set, signal.Map), e mutação manual pode ser sinalizada com signal.trigger(). Refs de template também viram signals (signal.ref()), aposentando o mecanismo do OWL 2.

Quem acompanha o ecossistema reconhece o movimento: é a mesma direção de SolidJS, dos signals do Angular, do Vue e da proposta de Signals no TC39 para entrar na própria linguagem. O Odoo não está inventando moda; está convergindo com a indústria.

O fim do env: plugins

O objeto env, aquele saco genérico onde tudo se pendurava (services, bus, configuração), morre. No lugar, um sistema de plugins com classe, lifecycle (setup()/destroy()) e importação tipada:

class Clock extends Plugin {
  value = signal(1);
  setup() {
    setInterval(() => this.value.set(this.value() + 1), 1000);
  }
}

class MyComponent extends Component {
  clock = plugin(Clock);  // tipado, com autocompletar
}

Os services do web client, como conceito de framework, saem de cena: viram plugins globais. Pra quem escreve módulo custom, essa é talvez a mudança de hábito mais profunda depois dos signals, porque praticamente todo componente custom hoje toca o env de algum jeito.

Props como função, templates com escopo de verdade

Duas mudanças menores no conceito, grandes no diff:

Props deixam de ser descritor estático e viram declaração por função, com tipos compostos (t.string(), t.boolean().optional(), t.object({...})). Validação a cada chamada e inferência de tipo no IDE, sem .d.ts gerado à mão.

Templates ficam mais parecidos com JavaScript e menos mágicos:

• acessar o componente agora exige this. explícito;
• t-esc vira t-out; t-slot vira t-call-slot; t-call só em nós <t>, com parâmetros por atributo;
• cada iteração de t-foreach ganha o próprio contexto, como um for...of com let;
• mecanismos internos de captura de escopo (capture, isBoundary e afins) somem, porque o escopo passa a se comportar como o da linguagem.

Além disso, onWillUpdateProps, onWillRender e onRendered deixam de existir (computed e effects cobrem os casos), o this.render() manual sai, e useComponent dá lugar a useApp(). A tabela de remoções do documento é longa, e vale a leitura na íntegra.

O que isso significa pra quem tem Odoo custom no Brasil

Primeiro: sem pânico. É um documento de design, sem versão alvo anunciada, e o próprio texto reconhece que a migração será “uma mudança muito grande”, com upgrade de código complicado, inclusive pra própria Odoo, que tem um dos maiores codebases OWL do mundo pra migrar.

Segundo: dá pra se posicionar desde já. Três práticas baratas hoje que vão baratear a migração amanhã:

1. Front custom enxuto. Cada widget, cada tela OWL customizada é um passivo de migração. A pergunta “isso precisa mesmo ser interface custom ou o padrão resolve?” nunca valeu tanto.
2. Menos acoplamento com env e services. Quanto mais o seu componente pendura coisa no env, maior o diff quando ele deixar de existir. Isolar esses acessos é barato agora.
3. Nada de gambiarra de reatividade. Cache manual, getter esperto, onWillRender pra pré-computar: tudo isso é exatamente o que o OWL 3 elimina. Código que hoje já usa o caminho simples migra quase sozinho.

Terceiro, e o ponto que me faz escrever sobre isso: essa discussão está acontecendo em público. O design doc está no GitHub, aberto, antes do código estar pronto. Quem constrói sobre plataforma proprietária descobre a quebra de compatibilidade no release note, depois que a decisão foi tomada. Quem constrói sobre open source lê a decisão sendo desenhada, comenta, e chega na migração com anos de preparo. Faz quase 15 anos que o nosso time vive dentro do ecossistema Odoo/OCA, e essa diferença de visibilidade é das coisas que mais sustentam a nossa opinião de arquitetura.

Se a sua operação roda Odoo com interface customizada e você quer entender o tamanho do seu passivo de front antes que o OWL 3 vire release, essa conversa a gente faz bem: me manda uma mensagem.

---

Fonte primária: OWL 3 Design Document (Odoo, documento em andamento).