Custom Snippet Parameters in Action Framework

Snippets are a great way to extend the Skuid framework and writing parameter driven snippets that allow allow data and components to dynamically run the snippet is a best practice that we try to stick to. When I see a specific model reference or a unique Id in a snippet, it’s in need of generalizing. It would be really handy to have a parameter string available in the action framework for the Run Javascript Snippet action. This would be a similar design to the query string option when using a page include. Here’s where I would envision this going:

There are a currently a few approaches to handling this functionality that work well with the current Skuid platform, but it would be helpful to be able to make it more declarative.

Here are a couple examples of passing custom parameters into a snippet to illustrate what I’m describing:

You can use the skuid.snippet.getSnippet method in the Goto URL actions, links in templates, or in javascript event listeners like onclick(). The issue with using this in a URL is that the browser will display the target string when hovering the link and it’s an invalid URL so you’ll get an error if you open it in a new tab or copy the link. In order to introduce an onClick event, you need to work with the HTML, like in a template. Note that you can use merge syntax with this approach. Here’s an example:

javascript:skuid.snippet.getSnippet(‘YourSnippet’)(‘parameter1’,‘parameter2’,‘parameter3’,paramter4,‘{{merge5}}’);

Another approach is to setup a model or UI only model and use an add row (or update) action and pass the values of your paramters into a model with corresponding fields. Then you have the model kick off the snippet and you can use the fields on the initiating row. Here’s an example of the parameters in the snippet in this scenario:

var params = arguments[0],
$ = skuid.$;
pollmodel = params.row.PollModel;
updatemodel = params.row.UpdateModel;
pollinterval = params.row.Polling_Interval;
checkModel = skuid.$M(pollmodel);
updateModel = skuid.$M(updatemodel);

There are ways to optimizing both of these approaches to get a lot of dynamic extension with snippets, but it took some work to get there and I believe that simply adding custom parameters to the snippet action would make it easier for the overall skuid community.

To expand on this thought, another place where Snippet parameters would be very handy would be in rendering logic.  We use a control table to toggle components on and off based on what we grant access to.  A component driven snippet would be helpful in managing this.  As an example, the navigation component entries don’t have much in the way of attributes to work with, so returning a snippet to impact rendering isn’t that helpful.  However if a parameter could be passed it would be super helpful.