UI Metadata Schema
Model the shape of your UI in JSON using a unified schema.
Usage in Lightning Web Runtime
This project is currently only used by Lightning Web Runtime and its corresponding validators.
Contributing
Standard fork git workflow applies.
- Edit only the schema affected by your change. Know that any definition changes can affect all schemas. Ensure you are not breaking someone else by looking at the files in the
/config
folder and verifying the impact of your schema change. - Further ensure you are not breaking someone else by running all tests.
- Add tests for your changes to make sure someone else does not break you.
- Submit the PR.
Definitions
Base Schema
The base schema attempts to define the common denominator between all UI shapes.
Definitions:
Name | Description |
---|
View | A view on a screen. Also known as a Page. |
Component | A reusable, composable fragment of UI. This is agnostic to technology, i.e. this could be a LWC component or a reusable HTML element. |
Region | A part of the view which may contain one or more Components |
BrandingProperty | A piece of data which stores visual information such as color or font. This is typically a key:value pair |
Route | A route contains metadata about a URL scheme, or any location specifier |
Theme | A theme is a complex type which contains metadata about your application's higher-level visuals |
ThemeLayout | A theme layout is just another name for a view |
View
A view is currently synonymous to a Flexipage in how it's used by Lightning Web Runtime. Views can live inside of other views, since they just map to a component definition today. Note that the view has a top-level component meaning it has to point to a single definition. A component itself may contain multiple regions each with multiple components, but a View may only have one top level component.
View
│ name
└─── component
|
| name
| attributes
| regions
│
└─── region
│ name
└─── components
|
└─── component
Component
A component is only called as such because today we have no other similar definition. A better name might be a fragment but this often refers to raw HTML with no bundled functionality and today that is not our case.
A component has a name, a map of attributes, and a map of regions which can contain more components.
Component
|
| name
| attributes
| regions
│
└─── region
│ name
└─── components
|
└─── component
Region
Regions are used primarily in a declarative setting to surface a primitive for drag and drop scenarios. Regions map 1:1 to the HTML concept of slots with some extra metadata. Regions are known in Communities for a very long time and they have more interesting characteristics in the declarative schema.
It's also interesting to think about a region and how it maps to a <section>
in HTML. Typically the header hierarchy should be reset for each new section in an HTML document, is that also the case with a region? What other similarities are there?
Region
│ name
└─── components
|
└─── component
Declarative Schema
🛠 Under Construction 🛠