A evolução que todo desenvolvedor Lightning Web Components esperava
A Salesforce introduziu no Spring ’26 um recurso que muda a forma como escrevemos componentes Lightning Web Components. As Complex Template Expressions permitem inserir expressões JavaScript diretamente no HTML do template, eliminando a necessidade de criar getters para cada pequena manipulação de apresentação. O recurso está em Beta, exige API versão 66.0 ou superior e já gera debate intenso na comunidade de desenvolvedores sobre até onde levar a lógica para o template.
Se você já cansou de escrever um getter só para concatenar nome e sobrenome, ou criar uma propriedade computada apenas para formatar moeda, esse artigo mostra exatamente o que mudou, como usar e onde não usar.
O problema que as Complex Template Expressions resolvem
Desde o lançamento do LWC, a filosofia de design foi clara: separar a lógica do JavaScript da camada de apresentação HTML. O binding de propriedades era simples e direto. Você referenciava uma propriedade no template e o LWC cuidava do resto através do virtual DOM.
O problema aparecia quando você precisava de algo minimamente computado. Concatenar strings, fazer uma verificação condicional simples ou formatar um número exigia criar um getter na classe JavaScript. Para um caso isolado, tudo bem. Em componentes reais, com dezenas de campos e formatações, isso significava arquivos JavaScript inchados de getters que existiam apenas para servir o template.
Considere o cenário clássico de um cartão de contato. Você quer mostrar o nome completo, formatar o telefone e exibir um badge de status. No modelo anterior, três getters. Com template expressions, zero getters.
Antes do Spring ’26, para concatenar nome e sobrenome, você precisava disso no JavaScript:
get fullName() {
return `${this.firstName} ${this.lastName}`;
}
E no HTML:
<template>
<div>{fullName}</div>
</template>
Com as Complex Template Expressions, o getter desaparece e a lógica vai para o template:
<template>
<div>{`Hello, ${firstName} ${lastName}!`}</div>
</template>
A diferença parece sutil em um exemplo isolado, mas em um componente de produção com 15 a 20 campos formatados, a redução de código é significativa.
Como habilitar o recurso no seu componente
A ativação não exige configuração no Setup. O gatilho é a versão da API do componente. Você precisa definir o `apiVersion` para 66.0 ou superior no arquivo de metadados `.js-meta.xml`:
<?xml version="1.0" encoding="UTF-8"?>
<LightningComponentBundle xmlns="http://soap.sforce.com/2006/04/metadata">
<apiVersion>66.0</apiVersion>
<isExposed>true</isExposed>
<targets>
<target>lightning__RecordPage</target>
<target>lightning__AppPage</target>
<target>lightning__HomePage</target>
</targets>
</LightningComponentBundle>
Componentes com versão de API anterior a 66.0 não suportam as expressões complexas. Se você tentar usar, o compilador vai retornar erro. A avaliação cai automaticamente para o binding de propriedades básico.
Importante destacar: o recurso está em Beta no momento. A própria Salesforce adverte claramente na documentação oficial para não usar em produção ainda. O uso recomendado é para desenvolvimento, testes, provas de conceito e aprendizado. Se você precisa dessa funcionalidade em produção hoje, mantenha os getters tradicionais até a disponibilidade geral.
Tipos de expressões suportados
A gama de expressões suportadas é ampla e cobre a maioria dos cenários de apresentação que desenvolvedores LWC enfrentam no dia a dia. Vamos detalhar cada categoria com exemplos práticos.
Template Literals
A categoria mais usada. Template literals permitem embedar expressões dentro de strings usando a sintaxe com crases e `${}`:
<template>
<div>{`User: ${firstName} ${lastName}`}</div>
<div>{`Status: ${isActive ? 'Active' : 'Inactive'}`}</div>
<div>{`Price: $${price.toFixed(2)}`}</div>
</template>
import { LightningElement } from "lwc";
export default class TemplateLiteralsComponent extends LightningElement {
firstName = "John";
lastName = "Doe";
isActive = true;
price = 99.99;
}
Note como o terceiro exemplo chama `toFixed(2)` diretamente no template. Isso elimina a necessidade de um getter `formattedPrice`.
Operadores Ternários
Condicionais simples ficam elegantes no template. Para casos de duas ou três condições, o ternário funciona bem:
<template>
<div>{isLoggedIn ? 'Welcome back!' : 'Please log in'}</div>
<div>{age >= 18 ? 'Adult' : 'Minor'}</div>
<!-- Ternário aninhado para múltiplas condições -->
<div>{score > 80 ? 'Excellent' : score > 60 ? 'Good' : 'Needs Improvement'}</div>
</template>
import { LightningElement } from "lwc";
export default class TernaryComponent extends LightningElement {
isLoggedIn = true;
age = 25;
score = 75;
}
O ternário aninhado é poderoso, mas exige bom senso. Se você precisa de quatro ou mais condições encadeadas, um getter com switch ou map provavelmente é mais legível.
Optional Chaining e Nullish Coalescing
Dois recursos do JavaScript moderno que finalmente chegam aos templates LWC. Optional chaining (`?.`) permite acessar propriedades profundas sem risco de erro quando um nível intermediário é null ou undefined. Nullish coalescing (`??`) fornece um valor padrão:
<template>
<div>{user?.profile?.settings?.theme ?? 'default'}</div>
<div>{settings?.theme || 'default'}</div>
<div>{data?.items?.length ?? 0}</div>
</template>
import { LightningElement } from "lwc";
export default class OptionalChainingComponent extends LightningElement {
user = {
profile: {
name: "John Doe",
},
};
settings = { theme: "dark" };
data = { items: [1, 2, 3] };
}
Isso resolve um dos problemas mais comuns em LWC: renderizar dados de APIs externas ou respostas de wire adapters onde a estrutura pode ser parcial.
Arrow Functions e Métodos de Array
Aqui está onde o recurso fica realmente interessante para componentes com listas. Você pode usar `map`, `filter`, `find` e `reduce` diretamente no template:
<template>
<div>{items.map(item => item.name.toUpperCase())}</div>
<div>{numbers.filter(n => n > 10).length}</div>
<div>{users.find(user => user.id === currentId)?.name}</div>
</template>
import { LightningElement } from "lwc";
export default class ArrowFunctionsComponent extends LightningElement {
items = [{ name: "apple" }, { name: "banana" }, { name: "cherry" }];
numbers = [5, 15, 25, 35];
users = [
{ id: 1, name: "Alice" },
{ id: 2, name: "Bob" },
{ id: 3, name: "Charlie" },
];
currentId = 2;
}
A terceira linha combina `find` com optional chaining. Se nenhum usuário com o `currentId` for encontrado, a expressão retorna undefined sem erro.
Expressões em Atributos e Eventos Inline
As expressões também funcionam em handlers de evento. Você pode escrever arrow functions inline para ações simples:
<template>
<button onclick="{() => myField = 'foo'}">Set Label</button>
<button onclick="{() => foo++}">Increment Foo</button>
<div>Field: {myField}</div>
<div>Foo: {foo}</div>
</template>
import { LightningElement } from "lwc";
export default class AssignmentComponent extends LightningElement {
myField = "";
foo = 0;
}
Isso é útil para componentes simples onde criar um método na classe JavaScript seria excessivo. Atribuições e operadores de incremento são permitidos dentro de arrow functions no template.
Compatibilidade com Diretivas LWC
As expressões complexas funcionam com as diretivas nativas do LWC, como `if:true` e `for:each`:
<template>
<template if:true="{state.isTrue && user?.isActive}">
{foo} {bar}
</template>
<template for:each="{getBentoItems()}" for:item="okazu">
<div key="{okazu}">
<a onclick="{() => taberu(okazu)}">{okazu}</a>
</div>
</template>
</template>
import { LightningElement } from "lwc";
export default class DirectiveComponent extends LightningElement {
state = { isTrue: true };
user = { isActive: true };
foo = "foo value";
bar = "bar value";
allItems = ["sushi", "tempura", "miso", "ramen"];
getBentoItems() {
return this.allItems.filter((item) => item !== "ramen");
}
taberu(item) {
alert(`Eating ${item}`);
}
}
Exemplo prático: Componente de cartão de oportunidade
Vamos montar um componente real que um desenvolvedor Salesforce construiria para uma página de registro de Oportunidade. O objetivo é mostrar uma visão consolidada com formatação de moeda, badge de stage e lista de produtos filtrados.
Arquivo `opportunityCard.html`:
<template>
<lightning-card title="{`Opportunity: ${record?.Name ?? 'Unnamed'}`}" icon-name="standard:opportunity">
<div class="slds-m-around_medium">
<!-- Formatação de moeda inline -->
<p class="slds-text-title_caps">
Amount: {`$${(record?.Amount ?? 0).toFixed(2)}`}
</p>
<!-- Badge de stage com ternário -->
<p class="slds-m-top_small">
Stage:
<span class="{record?.StageName === 'Closed Won' ? 'slds-badge_success' : 'slds-badge'}">
{record?.StageName ?? 'Unknown'}
</span>
</p>
<!-- Probabilidade formatada -->
<p class="slds-m-top_small">
Probability: {`${record?.Probability ?? 0}%`}
</p>
<!-- Data de fechamento formatada -->
<p class="slds-m-top_small">
Close Date: {record?.CloseDate ?? 'Not set'}
</p>
<!-- Lista de produtos filtrada -->
<template if:true="{products?.length}">
<h3 class="slds-text-heading_small slds-m-top_medium">Active Products</h3>
<ul class="slds-list_dotted">
<template for:each="{products.filter(p => p.IsActive)}" for:item="prod">
<li key="{prod.Id}">
{`${prod.Name} — $${prod.UnitPrice.toFixed(2)}`}
</li>
</template>
</ul>
</template>
<template if:false="{products?.length}">
<p class="slds-text-color_weak slds-m-top_medium">
No products added yet.
</p>
</template>
</div>
</lightning-card>
</template>
Arquivo `opportunityCard.js`:
import { LightningElement, wire, api } from "lwc";
import { getRecord } from "lightning/uiRecordApi";
import OPPORTUNITY_FIELDS from "@salesforce/schema/Opportunity";
const FIELDS = [
"Opportunity.Name",
"Opportunity.Amount",
"Opportunity.StageName",
"Opportunity.Probability",
"Opportunity.CloseDate"
];
export default class OpportunityCard extends LightningElement {
@api recordId;
@wire(getRecord, { recordId: "$recordId", fields: FIELDS })
record;
products = [];
connectedCallback() {
this.loadProducts();
}
async loadProducts() {
// Simulação de carregamento de produtos via Apex
this.products = [
{ Id: "01t000000001", Name: "Sales Cloud Enterprise", UnitPrice: 150.00, IsActive: true },
{ Id: "01t000000002", Name: "Service Cloud Enterprise", UnitPrice: 200.00, IsActive: true },
{ Id: "01t000000003", Name: "Legacy Product", UnitPrice: 50.00, IsActive: false }
];
}
}
Arquivo `opportunityCard.js-meta.xml`:
<?xml version="1.0" encoding="UTF-8"?>
<LightningComponentBundle xmlns="http://soap.sforce.com/2006/04/metadata">
<apiVersion>66.0</apiVersion>
<isExposed>true</isExposed>
<targets>
<target>lightning__RecordPage</target>
</targets>
</LightningComponentBundle>
Observe quantos getters esse componente não precisa. Sem as template expressions, você precisaria de `formattedAmount`, `stageBadgeClass`, `formattedProbability`, `formattedCloseDate` e `activeProducts`. São cinco getters eliminados. Em um componente maior, a economia é ainda mais expressiva.
O que você não pode fazer nas template expressions
A documentação oficial é clara sobre as limitações. Conhecer essas restrições é tão importante quanto saber o que funciona.
A palavra-chave `this` não é permitida. Você referencia propriedades diretamente pelo nome:
<!-- Inválido -->
<div>{this.property}</div>
<!-- Válido -->
<div>{property}</div>
Function declarations não são suportadas, apenas arrow functions:
<!-- Inválido -->
<div>{function getName() { return 'John'; }()}</div>
<!-- Válido -->
<div>{(() => 'John')()}</div>
Arrow functions com block body (chaves e return) não funcionam. Use expression body:
<!-- Inválido -->
<div>{items.map(item => { return item.name; })}</div>
<!-- Válido -->
<div>{items.map(item => item.name)}</div>
Operações assíncronas não são suportadas. Nada de `async`, `await` ou chamadas que retornam Promise no template. Essa restrição faz sentido: o template deve ser síncrono e determinístico para o virtual DOM funcionar corretamente.
O operador `new` é proibido. Se você precisa instanciar um objeto como `Date`, faça isso no JavaScript e exponha o resultado como propriedade.
Expressões em atributos devem estar entre aspas. Esse é um erro comum:
<!-- Erro: expressão complexa sem aspas -->
<div class={isActive ? 'active' : 'inactive'}></div>
<!-- Correto: expressão entre aspas -->
<div class="{isActive ? 'active' : 'inactive'}"></div>
Considerações sobre performance e manutenibilidade
A documentação faz um alerta que merece atenção: expressões muito complexas tornam o markup difícil de ler e manter. A própria Salesforce recomenda que você use seu melhor julgamento sobre o que funciona para você e sua equipe, tanto hoje quanto seis semanas depois da última vez que olhou o markup.
Isso é um conselho prático e não retórico. Expressões como `{items.filter(p => p.IsActive).sort((a,b) => a.Name.localeCompare(b.Name)).map(p => `${p.Name} ($${p.UnitPrice.toFixed(2)})`).join(‘, ‘)}` são tecnicamente válidas, mas ninguém consegue ler isso sem parar e pensar. Em casos assim, um getter bem nomeado como `activeProductsFormatted` é mais legível e testável.
Sobre performance, as template expressions são avaliadas pelo mesmo motor de reatividade do LWC baseado em virtual DOM. A Salesforce garante que as características de performance e o modelo de segurança são mantidos. Na prática, expressões inline são reavaliadas quando as propriedades referenciadas mudam, da mesma forma que getters reativos.
Um ponto de atenção: cada `fetch()` em um cursor ou cada operação de array no template cria um novo array a cada reavaliação. Para listas pequenas, imperceptível. Para listas com centenas de itens, pode gerar overhead. Se você perceber lentidão, mova a lógica para um getter memoizado.
Como a comunidade está reagindo
O recurso já gera discussão nas comunidades de desenvolvedores Salesforce. No Reddit, no subreddit r/SalesforceDeveloper, usuários debatem se vale a pena chamar o recurso de game changer. Alguns argumentam que a redução de boilerplate é real e melhora a produtividade. Outros preferem manter a separação clara entre lógica e apresentação, especialmente em equipes grandes onde nem todos dominam JavaScript moderno.
No LinkedIn, desenvolvedores compartilham exemplos práticos e a recepção é predominantemente positiva. A possibilidade de eliminar getters que servem apenas para formatar exibição ressoa com quem trabalha em componentes data-heavy.
O consenso emergente é que o recurso é valioso quando usado com moderação. Expressões simples de formatação e condicionais curtas no template aumentam produtividade sem sacrificar legibilidade. Quando a expressão passa de uma linha ou envolve múltiplas operações encadeadas, o getter tradicional continua sendo a escolha certa.
Impacto para equipes de desenvolvimento Salesforce
Para times que mantêm bibliotecas de componentes LWC internas, as template expressions abrem possibilidades interessantes. Componentes utilitários como formatadores de moeda, data e telefone podem ter sua lógica de apresentação simplificada. A redução de código JavaScript significa menos surface area para bugs e menos testes unitários de getters triviais.
Para consultorias e parceiros Salesforce, o recurso representa uma oportunidade de entregar componentes mais rapidamente. O tempo gasto criando e testando getters de formatação pode ser redirecionado para lógica de negócio propriamente dita.
Há também o aspecto educacional. Desenvolvedores vindos de frameworks como React e Vue já estão acostumados com expressões inline em JSX e templates. A chegada desse recurso ao LWC aproxima a experiência de desenvolvimento do que o mercado broader oferece, reduzindo a curva de aprendizado para novos desenvolvedores Salesforce.
Integração com outros recursos do Spring ’26
As Complex Template Expressions não chegam sozinhas. O Spring ’26 traz um conjunto coeso de melhorias para LWC que se complementam. Os Dynamic Event Listeners com a diretiva `lwc:on` permitem anexar handlers de evento dinamicamente via JavaScript, sem hard-coding no HTML. As GraphQL Mutations através do método `executeMutation` do `lightning/graphql` trazem operações de escrita direto no LWC sem Apex intermediário. O suporte a TypeScript para base components chegou ao `@salesforce/lightning-types`, oferecendo IntelliSense completo.
Usados em conjunto, esses recursos permitem construir componentes LWC mais expressivos, type-safe e com menos código boilerplate do que era possível até o Winter ’26.
Roadmap: quando usar em produção
Como o recurso está em Beta, a pergunta natural é quando poderá ser usado em produção. A Salesforce não anunciou uma data de GA no momento. O padrão histórico da plataforma sugere que features Beta introduzidas no Spring costumam amadurecer para GA em 1 a 2 ciclos de release, o que colocaria a disponibilidade geral entre o Summer ’26 e o Winter ’27.
Enquanto isso, a recomendação é experimentar em sandboxes e proof-of-concepts. Construa componentes usando template expressions, teste os edge cases que sua equipe mais utiliza, documente padrões e anti-padrões. Quando o GA chegar, sua equipe já terá maturidade para adotar o recurso de forma consistente.
Conclusão
As Complex Template Expressions representam a evolução natural do LWC em direção a uma experiência de desenvolvimento mais fluida e produtiva. A capacidade de escrever expressões JavaScript diretamente no HTML elimina uma categoria inteira de código boilerplate que existia apenas para servir o template.
O recurso pede bom senso. Expressões simples de formatação, condicionais e transformações de array curtas ganham muito ao migrar para o template. Lógica complexa, operações assíncronas e computações pesadas continuam pertencendo ao JavaScript da classe do componente.
Se você trabalha com LWC, vale dedicar uma hora para experimentar o recurso em um sandbox. Crie um componente de cartão de registro, substitua os getters de formatação por expressões inline e sinta a diferença. A redução de código é tangível e a legibilidade, quando bem aplicada, melhora.
Para se aprofundar, consulte a documentação oficial no Salesforce Developers, o guia do desenvolvedor para o Spring ’26 e o repositório LWC Recipes no GitHub, que já inclui exemplos atualizados com as novas expressões.
Fontes:
- Salesforce Developers Documentation: Template Expressions (developer.salesforce.com)
- Salesforce Developers Blog: The Developer’s Guide to the Spring ’26 Release
- Apex Hours: Apex Cursors Explained for Large SOQL Processing
- Salesforce Ben: Features for Salesforce Developers in Spring ’26
- Reddit r/SalesforceDeveloper: Community discussion on Complex Template Expressions
- LWC Recipes Sample App (GitHub: trailheadapps/lwc-recipes)