Views are a fundamental part of the Purple Experience application. Each view is assigned a specific name and path, making it easy to locate and access. Once set up, you can configure views by adding components and other necessary details.
Consider views as distinct pages within your app – like the main homepage, a list of articles from a specific category, a detailed article page, or even subscription offers.
Our component system offers flexibility, allowing you to design various views tailored to specific needs. This includes adapting views based on the device being used, whether a user is logged in, and other criteria.
You create and edit views in the views.json file.
There are three types of views that can be selected in the Experience Builder and are described here:
* = required field
Defines the class name which will be added to the DOM element "storefront-view". Therefore, we recommend using a lower-case name without spaces, so it works well as a CSS selector.
Describes under which URL the view will be accessible (exception: Using the URL resolver for dynamic paths). Note: The root view must have the path /, all other paths must not start with a slash.
If 'appBar' is set, it shows the top app bar with the matching ID from the appBar.json
If 'navigation' is set, it shows the bottom sticky navigation bar with the matching ID from the navigation.json
'content*' defines the content of the page, composed of different possibly nested Experience Components.
'data' stands for a list of Data sources that are required throughout the page.
The view will automatically be updated on any changes caused by app resumes or invalidations (e.g. caused by a login or a purchase). If 'pullToRefresh' is activated, manual updates via a pull gesture will also trigger an update.
The <title> Tag text is shown in the browser's bar and search engine entries. You can use $context, $functions or $global expressions, but it is not reactive (e.g. only set once). The <title> Tag is relevant to be set for SEO.
'postView ' is set for the simple opening of content based on 'postType'. We recommend using the URL resolver as it gives more flexibility.
Allows configuring the cache-control: max-age header. Specifies the value in seconds.
Adds metadata tags to the rendered HTML, e.g. for Open Graph properties.
Currently used for setting up traffective tracking.
Additional tracking parameters for view tracking events.
A string representing the JsonLD config to pass additional information to Search Engine Crawlers.
If true, the page is treated as an Error Page.
The Redirect View can be used to either statically or dynamically redirect the user to a different page.
Under which URL the page should be redirected.
The designated target view path to which it redirects.
A condition which needs to be fulfilled if the redirect is to be performed. Redirect will always be performed if not specified.
In the context of Server-Side Rendering (SSR), when this code is used to send an HTTP redirect, it does not impact client-side routing.
Here is an example of Redirect View:
The Global view, when available in your Experience set-up, is automatically loaded within the Experience. It loads all globally defined data sources from this view. These data sources are accessible from any view using the $global identifier.
Specify the complete set of global data sources that need to be accessible across all views.