Page Parameters¶
A page parameter is an arbitrary variable used to pass information into a Skuid page. There are different ways to pass in page parameters depending on the context and use case.
Types of page parameters¶
Including parameters in a URL is a common way to pass and retrieve information between pages in web development. Similarly, parameters can be passed between Skuid pages using:
Query string parameters¶
The most commonly used way to pass parameters is by including them in a query string, which is a collection of identifiers and key-value pairs preceded by a question mark. For example:
http://example.com/animals/mammals?felines=lion
In this example, the query string passed to the server, everything that comes after the ?
, is a parameter, felines, requesting all records of felines with the value “lion.”
Page parameters act the same way in Skuid: they allow additional information to be passed into a Skuid page.
On Skuid SFX, page parameters are added to query strings by model conditions, actions, and render/enable conditions through the Page/URL Parameter option, and, in some components, in the query string property.
When using page parameters in query string parameters, there are two important rules to keep in mind:
- The parameters must always come after a question mark (
?
), which indicates the beginning of a string of one or more URL parameters. - Every subsequent URL parameter must be prepended with an ampersand (
&
).
As long as query string parameters are used in this format, they are accessible within a Skuid page.
Note
Passing parameters into query strings is different in Lightning Experience. For more information, see Using Page Parameters In Salesforce Lightning.
URL Merge Parameters¶
Used on Skuid Platform, page parameters are included within URLs through URL merge parameters. For example, www.example.com/home/{myParameter}
.
On Skuid Platform, you can use URL merge parameters in model conditions, actions, render/enable conditions through the Page/URL Parameter option. They can also be used while constructing an app, and the pages within the app, by inserting URL merge parameters in the app and/or the page URLs. They can also be used for creating REST model conditions.
Using Page Parameters¶
Builders can access page parameters with model conditions, actions, render/enable conditions, and through the Page/URL Parameter option on some Skuid features.
Values are accessible through the {{$Param}} global merge variable.
For example, {{$Param.myRouteParameter}}
.
They may also be passed to Page Includes by setting the component’s Query String property to point to this global merge variable.
Using the Go to URL action with URL merge parameters¶
When creating a link with URL merge parameters in Skuid Platform, the process is similar to that outlined in Build an app navigation bar using the Go to URL action.
The key difference is that you point the URL to a URL merge parameter. This merge parameter could be a context-dependent merge variable or a global merge variable.
For example, the marketing/orders
path has a table listing each order, displaying some general information about each order. That table could have a row action that redirects to the following URL:
/marketing/orderdetails/{Id}
This redirect URL sends end users to a new route (/marketing/orderdetails
), just like the redirect URLs from the Build an app navigation bar using the Go to URL action topic mentioned above. The key difference is the added URL merge parameter, {Id}
, which references the model’s Id field. This means the context will be determined by the row the end user clicks, passing in that row’s Id value when clicked.
So, if the user clicks an order that has an Id of AuXun109274009
, Skuid sends the user to the detail page with the row item’s Id in the URL parameter: /marketing/orderdetails/AuXun109274009
The final step is setting a condition on the detail page that looks for the URL merge parameter:
Click the Models tab in the Elements pane.
Click the Orders model.
Add a new condition for the Id field.
Set the Value as follows:
- Content: Page/URL parameter value
- Value: Id
Set its condition state to Always On.
With this condition set, this model always looks for the URL parameter named Id
for the matching record Id.
Page parameter examples:¶
myapp.skuid.com/accounts
: In this example, no parameters are provided.myapp.skuid.com/accounts/{accountId}
: In this example, when a user visits this URL, Skuid pulls the “accountId” from the requested record and passes it to the URL. If the record’s accountId wasAuXun109274009
, the URL the user would see ismyapp.skuid.com/accounts/AuXun109274009
myapp.skuid.com/accounts/{accountId?}
: The addition of the?
makes the parameteraccountId
optional, so if there wasn’t a value foraccountId
, the user would be directed to/accounts
instead of receive aPage Not Found
error.
Note
Unless a parameter is marked optional with ?
, end users will see a Page Not Found
error if they navigate to that page without the parameter in the URL.
Using Page Parameters In Salesforce Lightning¶
When working in Lightning experience, builders will often use record Ids to create corresponding record detail pages. The Skuid Page Lightning component can determine the record Id based on the way Lightning structures URLs.
However, if you want to pass in other parameters besides an Id, they must be prefixed with Salesforce’s custom component namespace (c__
) and added via query string parameters.
For example, adding the namespace prefix to the parameter accountId
creates c__accountId.
Non-namespaced parameters are removed from the URL on page load.
It’s important to remember that, when namespacing URL parameters in Lightning, any reference made to them in a condition, action, etc, on a Skuid page is also namespaced.
Note
If moving pages from Salesforce Classic to Lightning, you’ll need to update the page parameters and any conditions, actions, etc with the namespace prefix in order to maintain functionality.