What’s New in Skuid?¶

undefined vs null: More friendly for old code!¶

In the Brooklyn Q2 update, Skuid changed a low-level, internal API used by several public APIs to return more specific results when used—returning undefined versus null when appropriate.

This can have pretty wide-ranging effects, so as of v11.0.2, we’re updating the most notable of the effected APIs to better accommodate existing code.

skuid.model.Model.getFieldValue() will now return null if the value of the field is one of the following:

• undefined
• null
• An empty string

Skuid on Salesforce: This Is API v40¶

Moving forward, Skuid on Salesforce will be at or above the API v40 threshold, which means that LockerService is now enforced when using Skuid in Lightning Experience. No worries: we’ve been prepared since the Brooklyn Q2 Point Release.

If you are seeing issues within your Skuid deployment in Lightning Experience, ensure that your custom code meets LockerService guidelines.

Skuid on Salesforce: CSS and Page Support Files¶

Previously CSS was not included within page support files—meaning styles included directly within Skuid pages may not work as intended within Lightning Experience. But as of Millau, any CSS styles included inline within Skuid pages will also be packaged in each page’s support file.

Image styles are now applied to the img element directly¶

In previous Skuid releases, any styles applied on the Image component were actually applied to the div element that surrounded the image as opposed to the img element itself. As of Millau all Image component styles are applied directly to the img HTML element. If your images no longer display as expected, check the styling of your Image components.

If you’re not familiar with HTML this may not sound like much. But the same Image components on existing pages may look different. For example, this the following component is configured exactly the same—with a width and height of 150px—but displays differently because of the way the styles are applied:

Pre-Millau

HTML behind the scenes [[]]

<div id="sk-1Pzyqj-165" data-rendered="true" class="sk-image-wrapper" style="width: 150px; height: 150px;">
  <img class="sm-image" alt="" src="<Skuid Logo URL>">
</div>

Millau

HTML behind the scenes [[]]

<div id="sk-1Pzyqj-165" data-rendered="true" class="sk-image-wrapper">
  <img class="sm-image" alt="" src="<Skuid Logo URL>" style="width: 150px; height: 150px;">
</div>

Skuid Chatter component and the skuid:page¶

We’ve updated Skuid’s Chatter to support client-side processed Salesforce models! This is especially helpful if you end up using offline mode, where all models are processed client-side.

However, if you deploy Skuid pages containing the Skuid Chatter component using the skuid:page Visualforce component, you’ll need to recreate Skuid’s Social Visualforce page.

1. Navigate to Build > Develop > Visualforce Pages.
2. Click into the Social Visualforce page in the skuid namespace.
3. Copy the markup.
4. Return to Build > Develop > Visualforce Pages.
5. Click New.
6. Label and name the new Visualforce page Social.
7. Paste the copied markup.
8. Click Save.

Server-side Models Cannot Depend on Client-Side Models for Conditions¶

While previous versions of Skuid allowed admins to set server-side model conditions to depend on UI-only models and other client-side processed models, this behavior was not supported and could have resulted in unexpected behaviors. As of the Millau release, doing this will now result in an error message.

To solve this issue, ensure that any models with conditions depending on a client-side model have the Process Model client-side property marked.

Salesforce Notes & Attachments versus Files¶

Per Salesforce Spring 17 release notes, in the near future, you’ll no longer be able to use the Notes and Attachments related list to attach files to records in Lightning Experience. Because of this, we recommend using the File Upload component’s new Content Document upload option for maximum compatibility.

When using the File Upload component with Lightning Experience, do not set the storage location to Attachment to Record, but instead use In Content Document (with Record Context), a new field that allows files to be uploaded and stored in the Content Document object, with a link to the Id of the record in context.

Note

While this shift is in Salesforce’s future, it’s smart to make this change now, so you (and your users) don’t get caught off-guard later.

Salesforce Record Types, Picklists, and JavaScript¶

Do …

• you use JavaScript to dynamically create models?
• you have record types in your Salesforce org?
• you include picklist fields (in those models that you dynamically create)
• your models create default rows?
• you need to access those default rows?

Then heads up!

The creation of default rows in models with record type picklists is now asynchronous. That means if you need to access that default row within your snippets, you’ll need to use an asynchronous function call.

Previously you could create the model and access its first row using:

1
2

var model = skuid.model.createModel('<all-of-your-model-xml>');
var row = model.getFirstRow();

But, now that the row is created asynchronously, you’ll need to update the code:

1
2
3
4

var model = new skuid.model.Model('<all-of-your-model-xml>');
model.once('initialized').then(function(){
  var row = model.getFirstRow();
})

If the model’s default row also contains default values based on the record type, you’ll need to use another asynchronous function call:

1
2
3

model.createRowAsync().then(function(row){
  // Any updates you'll be making to the row
});

undefined Resolves to null in UI-Only Formulas¶

Most UI-only formula users just need to know if a result exists or does not exist. But if you’re a JavaScript developer—or a philosopher—you know there are different types of non-existence when it comes to values/variables: undefined and null. And previously you would need to anticipate each one of these results in your UI-only formulas. No longer!

To make life simpler, Skuid UI-only formulas now always resolve undefined to null.

This means formulas can simply check for null instead of having to check for both. The undefined keyword will continue to function for backwards compatibility, but if you encounter any issues in especially complex formulas, change them to look for null instead.

Merge APIs Work More Consistently¶

If you’re a developer utilizing the utils.mergeAsTextInContext API, we’ve streamlined how this API handles both merges within its parameters and HTML alongside text.

Pre-Millau

Inconsistencies in the result based on whether or not there’s a merge variable:

Without a merge variable [[]]

1 2 3

utils.mergeAsTextInContext('<h1>Hello Bob!</h1>', { Name: 'Bob' }) > "<h1>Hello Bob!</h1>"

With a merge variable [[]]

1 2 3

utils.mergeAsTextInContext('<h1>Hello {{Name}}!</h1>', { Name: 'Bob' }) > "Hello Bob!"

If asText is true, then allowHTML was ignored regardless. HTML tags were stripped out and HTML characters were not escaped:

allowHTML is true [[]]

1 2 3

utils.mergeAsTextInContext('<h1>Hello > {{Name}} < </h1>', { Name: 'Bob' }, { allowHTML: true }) > "Hello > Bob < "

allowHTML is false [[]]

1 2 3

utils.mergeAsTextInContext('<h1>Hello > {{Name}} < </h1>', { Name: 'Bob' }, { allowHTML: false }) > "Hello > Bob < "

Millau

The result should now be consistent whether or not there is a merge variable:

Without a merge variable [[]]

1 2 3

utils.mergeAsTextInContext('<h1>Hello Bob!</h1>', { Name: 'Bob' }) > "<h1>Hello Bob!</h1>"

With a merge variable [[]]

1 2 3

utils.mergeAsTextInContext('<h1>Hello {{Name}}!</h1>', { Name: 'Bob' }) > "<h1>Hello Bob!</h1>"

HTML tags are no longer stripped out when asText is true and setting allowHTML to false will escape all HTML characters.

allowHTML is true [[]]

1 2 3

utils.mergeAsTextInContext('<h1>Hello > {{Name}} < </h1>', { Name: 'Bob' }, { allowHTML: true }) // allowHTML is true by default > "<h1>Hello > Bob < </h1>"

allowHTML is false [[]]

1 2 3

utils.mergeAsTextInContext('<h1>Hello > {{Name}} < </h1>', { Name: 'Bob' }, { allowHTML: false }) > "&lt;h1&gt;Hello &gt; Bob &lt; &lt;/h1&gt;"

Mobile Builder Deprecation Status¶

As of the Millau release, the deprecated Mobile Builder is no longer accessible except under the following special circumstances:

• App builders who have currently existing Mobile Builder pages will continue to have access to the Mobile Builder as long as those pages exist.
• Unpacking a page pack that includes Mobile Builder pages will re-enable Mobile Builder access until those mobile pages are deleted.

Again, as the Mobile Builder is deprecated, use of Skuid’s App Composer is encouraged for all mobile design moving forward.

Copying and Pasting Between Pages Is Not Supported¶

With Skuid’s new copy and paste features, it can be tempting to copy and paste components from one Skuid page into another. This behavior is not supported. Doing so may cause unexpected behaviors, and results may vary.