Developer Docs - Mobile Docs - Lava Application Content

C20.0M20.0

Displays content from a Lava Application and hosts its Helix interactions.

What it does

Settings

Using it with Helix

Helix attributes work in any block, including a plain Content block. What this block adds is a home for an application: a known application to resolve routes against, a server-rendered first screen with the application's merge fields, and a first load that can itself be a Helix request. See Requests and Targeting for the attributes themselves.

The ambient application

When Application is set, any Helix route inside the block can name just the endpoint. The app fills in the application's slug:

Choosing the first screen

The block's first screen comes from one of the two. Initial Endpoint wins when both are set.

Use Initial Template when the screen depends on the page. It can read PageParameter and write those values into the routes of the controls it renders, which is how a detail screen passes its id on to its endpoints.

Use Initial Endpoint to keep a screen's Lava in one place. The first screen comes from the same application as the requests that follow, so it is edited and secured alongside them, and one endpoint can serve both the web and the app by branching on ClientType. The route is a plain setting: Lava in it is not resolved, and nothing from the page is added to it.

When the first screen needs both, use Initial Template for a light frame and let an element inside it load the rest:

The initial load

With Initial Endpoint set, the block itself is the request's initiator and its target, so the response is swapped into the block in place of the loading indicator. It behaves like any other Helix response from there:

Initial Template content arrives through the block's own block action instead, the same way a Content block's dynamic content does, and a failure there also shows as an error notification in the block.

Notes