---
sourceDocument: Australia Build or modify applications
sourceDocumentLink: https://www.servicenow.com/docs/r/australia/application-development

 Release :

    - australia

ft:locale :

    - en-US

ft:publication_title :

    - Australia Build or modify applications

ft:clusterId :

    - cadev

bundleId :

    - cadev

workflow :

    - Development, Data, and Analytics


---

# Lux widgets

# Lux widgets {#ariaid-title1}

Release version: Australia  
Updated September 29, 2026  
![](https://www.servicenow.com/docs/portal-asset/ico-clock) 2 minutes to read
Summarize  
![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) Summarized using AI  
This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.  

## Summary of Lux widgets

Lux widgets are custom UI components created specifically for individual applications within the Lux platform.
Unlike generic widgets, every widget in a Lux instance is authored for a particular app.
These widgets are Lit custom elements registered assysaixwidgetrecords and extend one of two base platform classes, providing consistent styling and server-side rendering capabilities.
Show full answer Show less  
Widgets are organized in a project directory under a `widgets/` folder, where each subdirectory containing an `index.js` or `index.ts` file defines a widget. Non-widget directories (such as shared utilities) are automatically ignored during discovery.

## Key Features

* **Widget Discovery:** The build system detects widgets by locating subdirectories with an index file under `widgets/`. This supports coexistence of widgets and pages in a single project without conflict.
* **Base Classes:** There are two main widget base classes to choose from:
  * **AIUXElement:** Ideal for presentational widgets that receive data via properties from parents or pages. Provides styling, server-side data loading patterns, and telemetry.
  * **AIUXWidgetElement:** A superset of AIUXElement designed for discoverable, self-contained widgets that fetch and manage their own reactive data. It supports dependency injection and AI chat context integration.
* **Styling and SSR:** Both base classes offer Tailwind/DaisyUI styling and server-side rendering, ensuring consistent UI and performance benefits.
* **Data Handling:** AIUXWidgetElement populates reactive `this.data` from server results, enabling dynamic, self-sufficient widgets, while AIUXElement relies on external data passed down.
* **Upgrade Path:** Widgets can start with AIUXElement and later upgrade to AIUXWidgetElement without rewriting rendering logic, providing flexibility as needs evolve.

## Practical Implications for ServiceNow Customers

When building custom UI components in Lux, select the base class according to the widget's data management needs. Use AIUXElement for simple data-passing widgets, and AIUXWidgetElement for autonomous widgets that fetch and react to their own data. Proper directory structure and naming conventions ensure smooth discovery and integration into your application.

Adhering to these conventions and leveraging the base classes' features enables ServiceNow customers to create performant, maintainable, and discoverable widgets with consistent styling and server-side rendering support.  
A widget in Lux is a custom UI unit authored for a specific application. The platform ships no widgets; every widget on an instance was authored for an app.

This topic covers what a widget is, how it gets registered, and how the runtime resolves one by tag name. To learn how to build a Lux widget, see .

Everything you render in a Lux app is a Lit widget. A Lux widget is a Lit custom element, registered as a `sys_aix_widget` record, extending one of two platform base classes. Both give it Tailwind/DaisyUI styling, and server-side rendering (SSR)
safety; the difference is discoverability and how it gets its data.

## Project shape {#widgets__widgets-project-shape}

    my-widget/
                    ├── aiux.json              # { "basename": "my-widget", "scope": "x_demo_widget", "scopeId": "..." }
                    ├── now.config.json
                    ├── package.json
                    └── widgets/
                    ├── _shared/           # NOT a widget (no index.js): discovery skips it
                    │   └── chart.js
                    ├── weather/
                    │   └── index.js       # <x-demo-weather>
                    └── air-quality/
                    └── index.js       # <x-demo-air-quality>

Discovery convention: each sub directory of widgets/ that contains an index.{js,ts} is one widget. Sub directories without an index entry (helpers, fixtures, shared modules like
_shared/) are ignored silently, with no warning. Widgets and pages coexist: a project can contain only widgets/, only pages/, or both, and the build
discovers whatever is present.

## Choosing a base class {#widgets__widgets-choosing-a-base-class}

`AIUXWidgetElement` extends `AIUXElement`: it's a superset, so the real question is whether the widget needs what the superset adds. The choice affects runtime capabilities, not how the file
builds: both go through the same discovery, analysis, and bundling pipeline.
{#widgets__table-widgets-base-classes__entry__3}

| Base class | Use it for | Adds |
|-|-|-|
| `AIUXElement` | A presentational widget that receives its data through `@property` from a parent, or a page; every pages/\<route\>/page.js extends `AIUXElement` | Tailwind + DaisyUI styling, `this.loaderData`, `getLayoutData(key)`, the `static async loader(ctx)` convention, `this.server`, and `trackEvent()` telemetry |
| `AIUXWidgetElement` | A discoverable, self-contained widget that owns its data; the platform can register it and the AI can place it | Everything `AIUXElement` has, plus a reactive `this.data` populated by `this.server`'s result, dependency injection through `this.deps`, and chat context through `setAiContext()` |
[Table 1. Widget base classes]

{#widgets__table-widgets-base-classes}  
Note:  
`this.server` and `trackEvent()` live on the shared `AIUXElement` base and are available either way. `AIUXWidgetElement` is what makes `this.server`'s result land in a reactive `this.data`. Reach for `AIUXWidgetElement` when you need that reactive property, not to get `this.server` itself.

Start with `AIUXElement`. Reach for `AIUXWidgetElement` only when the widget genuinely needs to be a discoverable, self-fetching unit; because it's a superset, you can upgrade later without
rewriting render logic. Pages are always `AIUXElement`. Never extend `LitElement` directly; that loses the automatic styling, `loaderData`/`data`, and the loader
and server-script conventions.