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. How you access this tab depends on your platform:

  • Skuid on Salesforce: Navigate to Configure > Component Packs
  • Skuid Platform: Navigate to Settings > 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. These essential component packs are also included in Skuid Platform, but do not display in the Component Pack list.

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.

Skuid Platform [[]]

  • Name: Correlates to the id property of your component pack as it appears in the manifest files. This must be set within the component pack, and it may not be edited from this screen.
  • Active: Determines whether or not the component pack is activated and able to be used within the App Composer.
  • 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.
  • Created By: Indicates who first uploaded the component pack.
  • Last Modified By: Indicates who last edited the component pack.

Uploading a component pack with the same id property as an existing pack will be considered modifying the component pack.

Skuid on Salesforce [[]]

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

Skuid Platform [[]]

  1. In the Skuid main menu, navigate to Configure > Component Packs.
  2. Click fa-sign-in Import Component Pack.
  3. In the Import Component Pack dialog, click fa-cloud-upload Upload and navigate to the component pack zip file you want to use. Alternatively drag and drop the file on to the Upload button.

Your component pack is now uploaded and ready for use. You can update existing component packs by uploading a new zip file with the same component pack id.

Skuid on Salesforce [[]]

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.

Note

It is not currently possible to export component packs in Skuid Platform.

  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.