Upload and Manage Component Packs

Component packs, as their name implies, are zipped archives of one or more custom components for use within Skuid. Making use of component packs— whether they are developed by your team, yourself, or Skuid developers across the web—is a great way to extend the power of your Skuid implementation.

Packs are managed in the Component Packs tab. You access this tab by navigating to Configure > Component Packs.

In this tab, you’ll see a list of available component packs. You can modify the properties of existing packs or delete them. When deleting component packs in Skuid on Salesforce, you must also delete the static resource containing the pack.

Note

In Skuid on Salesforce, by default, Skuid displays a list of essential Skuid component packs:

  • skuidcore
  • skuidvis
  • skuidmobilecore
  • skuidvismobile

You cannot delete these component packs; they contain the primary Skuid components library, the standard visualization components, and their Skuid Mobile counterparts.

Properties

From the Component Packs tab, you’ll see a table with the following fields. Each field serves a purpose in telling Skuid how to properly use the component pack.

  • Name: Correlates to the id property of your component pack as it appears in the manifest files. This field is case-sensitive and must match the component pack ID exactly.

    Warning

    Do not change the pack Name unless you are also able to update the manifest files and any necessary resource files to reflect this change; otherwise, the App Composer will not recognize the component pack.

    Note

    If you did not develop this component pack and are seeing issues, verify the component pack id with the developer.

  • Resource Name: Correlates to the name of the static resource of the component pack.

    Note

    If you change the name of the pack’s static resource, you must also change the Resource Name in this tab. Otherwise Skuid will be unable to locate the pack.

  • Resource Namespace: (Optional) Determines the JavaScript namespace of the component pack.

  • Pages available in: Determines if the pack’s components should be available for in the App Composer (Desktop), the deprecated Mobile Composer (Mobile), or both.

  • Load Order: Determines the actual order in which packs are loaded in the App Composer, starting from 0. If your component pack contains dependencies that require resources contained in other packs, set it to load after those packs.

  • Active: Determines whether or not the component pack is activated and able to be used within the App Composer.

Additional properties

Click Additional Properties fa-wrench to open a drawer with the following properties:

  • Runtime Definition File: Used by Skuid to locate the runtime definition file. Typically skuid_runtime.json. Do not modify unless you are sure these definition files have different names.

  • Builder Definition File: Used by Skuid to locate the builder definition file. Typically skuid_builders.json. Do not modify unless you are sure these definition files have different names.

  • Cache Package Definition: Determines whether or not to cache the component packs files server-side. Doing so can result in a performance boost.

    Note

    If you check the Cache Package Definition box, you must click Update Cache anytime you update the component pack so that your Skuid UI will reflect the changes you’ve made.

Update the cache

If you checked the Cache Package Definition box on the component pack, click Update Cache fa-cloud-upload to update the cache so that any changes to the component pack are reflected in the App Composer and runtime.

Upload Component Packs

While you are free to create your components and build your own component packs, you can also use component packs assembled by others within your own Skuid org—without any code.

To add a new component pack, follow the steps below:

First, you’ll enable component pack usage in Skuid’s configuration settings by checking the box next to Use Component Packs. In most cases, this box is checked by default.

Note

If you’re upgrading from a previous version of Skuid, this may be unchecked.

Upload component packs

In order for Skuid to recognize and utilize your component pack, you’ll need to do two things:

  1. Upload that zipped file to a Salesforce static resource that Skuid can access.
  2. Create a reference to that static resource within Skuid’s component pack list.

In Salesforce

  1. Navigate to Setup > Develop > Static Resources.
  2. Click New.
  3. Enter the name of the Salesforce static resource containing your component pack zip file.
  4. Click Choose File to upload the file.
  5. Set Cache Control to Public.
  6. Click Save.

Once you’ve uploaded your component pack as an accessible static resource, it’s time to let Skuid know it’s available for use.

In Skuid

  1. In the main Skuid menu, click Configure

  2. Select the Component Packs tab.

  3. In the Component Pack tab, click fa-plus-circle at the top of the table to add a new component pack.

    Be sure to use plus sign—also known as the Add New Component Pack button—create a new row within your Component Pack table.

    Note

    Do not click fa-plus-circle New Component Pack. This begins a different workflow designed to give examples for building component packs, not uploading already-built packs.

  4. In the Component Pack table, fill in the necessary component pack fields.

  5. Click Save.

Your component pack is now uploaded and ready for use.

Export Component Packs

If your component pack is no longer available on your local drive, or if you have modified the pack since using it within your org, you may want to export that component pack for use with other orgs.

To do so, you’ll need to download the component pack’s file.

  1. In Salesforce, navigate to Setup > Develop > Static Resources.
  2. Click the Name of the static resource containing component pack.
  3. Click View file under the Size field.
  4. Save the component pack.

To upload the saved pack to another org, repeat the steps as listed in Upload Component Packs.

Troubleshooting

Component packs are assembled using several files that refer to each other and must be properly formatted to work correctly. If different aspects of your custom component are not working, then you may need to troubleshoot the construction of the component pack.

You may need to verify these elements with the component pack’s developer:

  • the paths indicated in the manifest files are correct
  • the runtime and manifest files are mapped correctly
  • the name of the component pack matches the id property of the component pack in the manifest files
  • the resource name matches the name of the static resource

For more information, see Building Component Packs.