Skuid Developer Resources

Admins can use Skuid to create their dream UI with no code (no kidding), but that doesn’t mean Skuid implementations can’t be dramatically extended with code. As a developer, you have the tools to create powerful in-page JavaScript snippets, custom Skuid components tailored for your use case, or a beautifully-styled user interface that takes advantage of your existing Apex code. The sky’s the limit!

However with great power comes great responsibility—and presumed knowledge. Before you begin, you must have a basic understanding of Skuid as a web technology and the web languages Skuid makes full use of, including HTML, CSS, JavaScript and jQuery. Tutorials for these languages are beyond the scope of our documentation, but many helpful and free resources exist online, such as the Mozilla Developer Network (or MDN):

As a developer using Skuid, you can also make heavy use of the Skuid JavaScript API, which is linked in this site’s navbar. Our API documentation is always growing, so check back frequently and use it as a reference if you encounter functions or objects you are not familiar with and would like to know more.

Before You Begin

As you may have guessed, the material in this developer guide is aimed at developers. If you are a database administrator, a lot of the content in this section may not be applicable to your expertise. While we’ll do our best to guide beginners along, please know that in this guide, code will be used. If you feel out of your depth, or would like to see if there is a declarative option for what you wish to accomplish, please visit our User Reference.

Still with us? Congratulations! But don’t think you can get by in this Dev guide without knowing the basics. If you do not have a working knowledge of Skuid’s declarative functionality, please familiarize yourself with our User Reference before proceeding. (You wouldn’t let a doctor operate on you if they hadn’t taken an anatomy class!)

If you have not read the topics below, we recommend that you take the time to do so now:

  1. Get started with Skuid
  2. Connect to your data
  3. Assemble your pages
  4. Deploy your pages
  5. Adjust for Maximum Productivity

Going forward, it is assumed that you already know the Skuid Admin topics covered in these five items, such as how to include fields within a model, modify a component’s properties, or use the action framework. If you don’t have that knowledge, you may have trouble following this guide.

How You’ll Interact with Skuid as a Developer

Something to remember as you begin your developer journey: Skuid was built with Skuid. Each part of Skuid and its components is either a Skuid page or a static resource assembled with the Skuid JavaScript API (with a little extra magic thrown in).

In the same way that you use the Skuid tool to create your UX, you’ll be using the same developer tools we employed to build our product to extend yours. So what does that look like?

Extending Skuid with JavaScript

JavaScript is essential to expanding Skuid as a developer. You’ll be writing, debugging, and otherwise completely living in JavaScript.

Although we continue to add additional core Skuid components over time, we’ve made it easy for you to create your own snippets and custom components using Skuid’s JavaScript API. To get started, check out our JavaScript overview, our guide on using snippets, and our guide to creating custom Skuid components.

Styling your Pages with CSS

While it is best practice to use Skuid’s Theme Composer for styling your overall user experience, there are instances where creating custom CSS can greatly benefit your Skuid implementation. As a developer, knowing how—and when—to use CSS in Skuid is valuable knowledge.

Invoking Apex Logic

If you’re coming from a Salesforce background, then you’ve probably written a lot of Apex to support your business needs. No need to abandon it—we’ll teach you how to invoke and use all that Apex within Skuid.

How Skuid Accesses Your Custom Code

Whether you’re using a new custom component, embedding CSS, or invoking Apex—you’ll be doing so by storing the code in a resource that can then read by Skuid. There are three types of resources you’ll be using to do this:

  • In-line resources: Primarily for one-off uses of code within single pages. Mostly, this takes the form of in-line snippets, but you may also have in-line CSS. Some examples include creating a custom JavaScript action, invoking Apex, or styling a specific element with CSS.

    Note

    When deploying Skuid on Salesforce using the Skuid Page Lightning component, in-line resources can only be accessed through page support files. Pages that contain in-line resources—but have no corresponding page support file—will not load.

  • External resources: If you have your code stored elsewhere, Skuid also allows you to use external JavaScript and CSS resources. Simply have your resource URL handy!

  • Static Resources: If you’re consistently using a piece of code—such as a JavaScript snippet or CSS stylesheet—if you’re building a component pack for your custom component, or if you’re an ISV developing a managed package, you should store that code within a Salesforce static resource. Static resources are the most dependable way to use code in conjunction with Skuid, and they have a variety of advantages:

    • Static resources can be cached, leading to lower page load times.
    • They can be stored in a source control repository _separate_ from your Skuid pages.
    • They do not require the use of page support files.

    In short, if you’ll be extensively using custom code with Skuid on Salesforce, do so using static resources.

In addition to these methods, you can also directly interact with the Skuid JavaScript API from your browser’s console. Useful for experimentation and debugging, you should become familiar using the browser console in conjunction with Skuid.

In-line resources and page support files

To prevent rogue code from running within pages, LockerService curbs the use of in-page JavaScript and similar resources. To address these security standards while preserving existing functionality, Skuid stores in-line JavaScript code and in-line CSS within a Salesforce static resource known as a page support file.

Warning

If you are an ISV developing managed packages for distribution, do not use in-line resources and page support files. This is intended strictly for users who rely on in-line resources within their own organization—at most moving between connected Salesforce orgs.

Manually generate page support files for multiple pages

  1. Navigate to Configure > Org Preferences > Page Support Files.
  2. Click Generate Support Files for All Pages.

Skuid will then begin generating static resource files for each Skuid page that contains in-line JavaScript or CSS—which is treated as a Salesforce deployment.

Warning

This process can take some time. Do not refresh, leave, or close the page

This is also possible through the Skuid Pages list:

  1. Select which Skuid pages to generate files for.
  2. Click the arrow fa-caret-down beside Mass Update Selected Rows.
  3. Click fa-magic Generate Page Support Files.

Manually generate support files in the App Composer

You can generate page support files for a single page from the App Composer by clicking More Page Actions > fa-magic Generate Support File.

Automatically generate support files on page save

If you wish to ensure that static resources do not become outdated, Skuid provides an option to generate these files after every page save.

  1. Navigate to Configure > Org Preferences > Page Support Files.
  2. Check Generate Skuid page support files on page save.
  3. Click Save.

Each time a page is saved, its support file will now be generated with the latest in-line JavaScript and CSS. If the page is a master page, then all of its child page support files will also be generated.

Note

Because master and child pages can be generated as a batch, saving a master page will typically incur only one API call (as opposed to several calls).

Long save times may occur when saving pages with this option enabled; this may be related to the number of in-line resources being packaged into a page support file. To reduce the save time on in-line resource heavy pages, consider disabling this option and moving all in-line resources to static resources.

Note

With this option enabled, every page save will incur a Salesforce API request to initiate a deployment. For more information, see the API Usage section.

Verifying generation

Static resources for page support files are inserted into the Salesforce org through Salesforce deployments, and their generation can be verified in Salesforce Setup.

  1. Navigate to Environments > Deploy > Deployment Status.
  2. Click View Details beside the deployment that corresponds with the date and time that you generated the static resources.

The individual page support files can be viewed in Salesforce Setup by navigating to Custom Code > Static Resources.

Warning

If the static resource supporting a Skuid page is deleted, that page will not function correctly.

Note

The page support files are not intended to be modified directly. Changes to custom code should be made directly to the page’s in-line resources through the app composer. Propogate the custom-code changes by manually generating page support files or by clicking Save, if the property for automatically generating page support files is checked for the org.

Moving pages that need page support files

When moving pages from one Salesforce org to another, perhaps as part of a sandbox refresh or deploying your pages to production, there are some considerations for pages that require page support files.

If you are moving Skuid pages that utilize in-line resources to another Lightning-enabled org, do not package your page support files for deployment. Doing so will actually result in errors because the page support files are org-specific.

Instead, package your Skuid pages as usual through page packs. Whenever a page pack is unpacked, page support files (when necessary) are automatically generated if the property for automatically generating page support files is checked for the org.

If the property is not checked, then pages support files can be manually generated for the imported pages.

API Usage

Because static resource generation is accomplished through a deployment, Skuid must use Salesforce API endpoints to facilitate the process. This means that static resource generation incurs API requests.

Skuid optimizes requests using batching to reduce the impact on API limits—which is particularly useful on the initial generation of page support files.

If your organization relies heavily on API requests within your Salesforce org, weigh the benefits of in-line resources—and regenerating the static resources with each page save—versus storing all JavaScript code within static resources manually.

To reduce the number of API requests (and deployment statuses), consider turning off Generate Skuid page support files on page save for the org. Manually generate page support files as needed.

For more information about API request limits within different Salesforce org types, see the Salesforce Developer Limits Quick Reference.

Custom Code and LockerService

While Skuid on Salesforce, its features, and its components are LockerService compliant, you must ensure that your own custom code is compliant as well. Many new security rules and modern JavaScript standards are enforced within LockerService, such as “use strict” and others. Additionally, forthcoming Content Security Policy (CSP) restrictions will be implemented as well.

If your Skuid site includes custom components or snippets, ensure that code follows Salesforce’s Developing Secure Code.

Also note that, if you’ve implemented server-side behaviors with Apex code in custom components, these behaviors will no longer be possible within LockerService.

Note

This applies to both in-line resources and static resources.