LWC in Winter ’27: Template Expressions and Third-party Web Components

LWC Winter ’27 makes two features generally available that Salesforce developers have wanted for a while: complex template expressions and support for external web components. Template expressions let you put more display logic in your HTML templates. The new directive for external elements lets you render existing custom elements without an iframe workaround.

This guide explains how each feature works, where it fits in real Salesforce projects, and what to check before you adopt it. You will find short code samples, a comparison table, a pre-launch checklist, and a rollout plan you can hand to your team.

 

What Changed in LWC Winter ’27

Both features started in beta. The official release notes now list them as generally available, and the external web component feature has no changes since its last beta release.

• Template expressions: use a broad subset of JavaScript expressions directly in a template. Components need API version 66.0 or later.
• External web components: add the lwc:external directive to a custom element, and LWC renders it as a native web component.

This is what developers using Winter ’27 LWC new features would most likely use in their day-to-day work since it affects just about any component that renders the screen. The two LWC new features ship with Salesforce Winter 27 release. Salesforce Winter 27 release is rolled out to production gradually. Developer guide pages may still show beta, but release notes are the authority on that.

 

Writing Display Logic Directly in the Template

The template expressions keep small layout decisions close to the code that needs them. This is an example list that chooses a CSS class and makes a label without using a getter:

<template>
  <template for:each={accounts} for:item=”acc”>
    <li key={acc.Id} class=”{acc.Rating === ‘Hot’ ? ‘priority’ : ‘standard’}”>
      {`${acc.Name} (${acc.Industry ?? ‘No industry’})`}
    </li>
  </template>
</template>
 

The ternary chooses the class, and the template literal builds the text. You bind the raw records and let the template do the formatting.

Where Expressions Save the Most Effort

• Text formatting: Combine names, create fallbacks, or generate labels using template literals.
• Class selection: Change styles depending on field value without having to generate a class using getters.
• Conditional rendering: Protect from undefined values with &&, ??, or optional chaining before rendering them.

Each one replaces a display-only getter. That means fewer lines in the JavaScript file and one less place to look when the screen shows the wrong value.

Rules That Trip People Up

• Wrap complex expressions in attribute values in double quotes.
• Skip this. Write {name}, not {this.name}.
• Use arrow functions with expression bodies only. items.map(i => i.name) works, but block bodies do not.
• Keep new, await, async arrows, assignments, and ++ out of templates. That logic belongs in JavaScript.

Keep Expressions Readable

Salesforce advises using expressions for presentation logic only. If you would struggle to read it six weeks later, move it back into JavaScript. The full list of unsupported syntax sits on the considerations and limitations page.

 

Rendering an Existing Web Component with lwc:external

Web components can be of any framework or even plain JavaScript and Salesforce refers to the MDN web component examples as the initial point. They can be added with an iframe or lwc:dom=”manual”, but the developer’s guide suggests lwc:external since the element will be rendered natively inside your template.

This directive informs LWC that the given tag is a custom element external to your component library. The given sample involves the relative time element:

<relative-time datetime={date} lwc:external></relative-time> 

The element’s script comes from a static resource, loaded once inside the component class:

async renderedCallback() {
  if (this.loaded) return;
  this.loaded = true;
  await loadScript(this, timeElements);
  this.date = new Date();
}
 

In real code, wrap loadScript in a try/catch. Using third-party web components in LWC also requires Lightning Web Security, because Lightning Locker does not support custom elements.

Passing Data and Events

Now that the element is placed in the document, you must supply the element with the information and respond to its activity. There are several guidelines that apply to most situations:

• Supply the data through attributes, properties, or lwc:spread. By default, LWC assigns attributes, while it assigns properties only if they exist.
• Declaratively defined event listeners handle only lowercase event names.
• For names with capital letters or hyphenation, use addEventListener() in JavaScript code. Slotting is not allowed in synthetic shadow, and dynamic component creation is not available in lwc:external.

Picking the Right Route for Each UI Need

Salesforce suggests checking for a base component or an AppExchange package before you pull in an external element. This table shows where each route fits.

Route	Good fit	Watch for
Base component	Standard inputs, dates, tables	Limited to what the component exposes
AppExchange package	Ready-made features with vendor support	Package review and licensing
lwc:external	Existing custom elements, design-system pieces	Needs Lightning Web Security and a pre-bundled script
iframe	Isolated pages you cannot change	Styling and messaging limits, not the recommended route

What to Check Before You Ship an External Component

Run every candidate through this list first:

• Script loading – loadScript cannot be used for ES modules. Instead use the bundled IIFE/UMD version.
• Dependencies – Components that require external npm dependencies or require a build step are not possible as LWC doesn’t import npm modules.
• Element querying – Components that query document.getElementById will not work in the context of shadow DOM. The solution is to use template references.
• Experience Builder sites – External web components do not work in these sites when Lightning Web Security is enabled.
• Size limits – A static resource can be up to 5 MB, and an LWC module’s JavaScript file up to 1 MB.
• Security review – Read the script source and check its licence before it goes into a shared org.
• Support – Salesforce does not support third-party components, so your team owns updates, licence checks, and security review. The known issues list is worth reading before you commit.

Where These Changes Help in Real Projects

The scenarios below are hypothetical, not customer stories.

• A status-heavy record list: Badges, fallback text, and formatted names live in one HTML file. Reviewers see the display rules without opening the JavaScript.
• A shared design system: A team with in-house custom elements can reuse them inside Salesforce instead of rebuilding each one as an LWC, provided the bundle format fits.
• A dashboard-type component: Multiple smaller components, each with individual formatting rules, are still readable since all the rules are defined right next to the affected element.
• A tiny utility component: A relative timestamp, a date picker, or a charting component from a third-party library may be used as a replacement for a custom-made one.
• A page driven by data: Labels, classes, and visibility rules depend on the record data, thus changing the field requires changing the template rather than introducing a new getter.

A Practical Rollout Plan

1. Test LWC Winter ’27 features in a preview sandbox or Developer Edition org prior to production upgrades.
2. Specify apiVersion 66.0 or above for components that require using expressions. All other versions will automatically default to simple binding, while complex expressions in them will fail to compile.
3. Begin with just one low-risk component, such as a read-only card, to understand how your team writes and evaluates expressions. Count how many times reviewers ask you to put an expression back into JavaScript and make this number the limit for your team.
4. Add a review policy: expressions cannot be used as anything other than presentation layer.
5. Package, analyze, and approve external components prior to putting them into a shared org.
6. Work through a release readiness checklist so nothing else in your org surprises you after the upgrade.

Conclusion

LWC Winter ’27 gives developers a cleaner way to write display logic and a supported way to reuse components built outside Salesforce. Expressions cut display-only code, and external elements cut rebuild work.

The trade-off is discipline. Keep expressions short, vet every external script, respect the documented limits, and test in a sandbox before your org upgrades.

If you are planning how these capabilities fit your component architecture or an upcoming build, a review of your current Lightning Platform development setup is a good place to begin.

 

FAQs

Are Salesforce LWC Winter 27 suitable for production?

Both the features are marked generally available in release notes, but there is no change in the external web component feature from beta. Check the status in your own org’s release notes and test the feature in a sandbox before building any application using it.

Will already existing components get updated with LWC Winter ’27?

It is not fully automated. Template expressions require API version 66.0 or above and complicated template expressions on lower versions will give compilation error. The external element works only when the lwc:external is used in the tag.

Can I use any web component from npm?

No. LWC does not allow importing of web component from npm and thus an IIFE or UMD file needs to be pre-bundled from the static resource.

Do template expressions take place of getters?

No. Template expressions are good for display purposes only. Any logic involving async, assignments, etc., should be done in JavaScript.

For more insights, updates, and expert tips, follow us on LinkedIn.