Skuid and Code

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, 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 Concepts.

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 Skuid Concepts before proceeding. (You wouldn’t let a doctor operate on you if they hadn’t taken an anatomy class!)

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.

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 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:

  • Inline resources: Primarily for one-off uses of code within single pages. Mostly, this takes the form of inline snippets. Some examples include creating a custom JavaScript action or invoking Apex.

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

  • Static Resources: If you’re consistently using a piece of code—such as a JavaScript snippet—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.

    In short, if you’ll be extensively using custom code with Skuid SFX, 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.

Inline resources and page support files


In previous releases, to abide by security guidelines for functioning within Salesforce’s Lightning Experience, Skuid stored each page’s inline JavaScript code within a Salesforce static resource known as a page support file. As of release 12.2.0, page support files are no longer needed for inline resources. If using 12.2.0+, you may delete any existing page support files within your org.

Custom Code and LockerService

While Skuid SFX, 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.


This applies to both inline resources and static resources.