For views that can be found on a fixed path, each view in the views.json has a path property which defines under which path they can be accessed.
You can omit the leading slash for all but the root path (e.g. root is "/" but "/home" should be just "home")
By default, the "/" path is opened when visiting the website or starting the app. A Static Redirect can be set for the path "/" if it is desired to show the initial page on a different path.
Static redirect can be set in the views.json to instantly redirect to a different path when the user hits the redirect's path, optionally dependent on a condition. On web, they are returned with an 301 redirect status (can be changed with the statusCode field).
To add a redirect, switch the top dropdown from View to Redirect and configure the redirectTo target.
You can set and configure dynamic paths in the views.json file in Experience Builder.
You will find it here: default/storefront/assets/views.json.
The views.json supports dynamic path-segments through a specific format. When a segment should be dynamic, the segment has to start with a colon, followed by the variable name the runtime value will be assigned to. E.g. you can define a path like post/:postSlug
In the example above, post is a fixed segment and :postSlug is a dynamic one.
The Purple Experience will check which value is used at runtime and stores this value in the variable postSlug.
postSlug = purple_post
postSlug = anotherPurplePost
not valid for this configuration, but a separate configuration for the path post can be configured
not valid for this configuration, but a separate configuration for the path post/:postSlug/:anotherVariable can be configured
You can use the variables inside a data source filter to filter the shown data on this page by this value. Just use the variable name as a filter value in the colon notation instead of a fixed value or the already know $context approach.
If you want to navigate to a view with dynamic segments, e.g. through a tapCover configuration, but the value to use to interpolate those segments is not known on configuration time, e.g. in a data source driven list, you can again use the colon notation in combination with with the dot notation for an object path.
- the colon indicates, that an interpolation is needed
- followed by a dot separated object path indicating the location of the value to use within the current context
For example, a NavigationAction path of issue/:issue.properties.slug leads to a link target, where the value of the second segment is taken from an issue object in the specific component context, e.g. because the data source used for the list is of type "issue".
In this issue object, the value is taken from the slug field in the properties object in the issues object.
If the content is something like this:
Then the navigation would lead to issue/exampleSlug