This package has been deprecated

Author message:

This package is no longer in use. Please see @communities-webruntime/metadata-schema

@webruntime/metadata-schema

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.

1. 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.
2. Further ensure you are not breaking someone else by running all tests.
3. Add tests for your changes to make sure someone else does not break you.
4. 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 🛠