So… I’ve been diving into all things Lightning/Skuid as it’s increasingly requested of me.
I’m really quite excited to dive into Lightning Events as it seems to be the most crucial understanding needed for this.
I have a few questions on the “Publish Event” action.
1. Publishing Scope. Do I have the correct understanding when “converting” to terms?
a) “All active pages and Lightning Components” is an Application Event.
b) “All active pages” is a Component Event.
c) “Only this page” is an event that doesn’t publish beyond the current Skuid page.
2. Event Name. Currently there’s a short list of events in a drop down.
a) I assume these are the most commonly used events?
b) Can we assume that all these standard events can be used?
c) Additionally, custom Events can be triggered by simply knowing their name?
3. Event Parameters. Seemingly this is handled like “Show Toast Message”. As in, parameters automatically exposed on the skuid page builder. Is this able to handle all possible types of parameters? Such as a list of records?
Event-Triggered Sequences
1. Event Name.
a) There is a drop down list of events. Are these there as there a handler function that you’ve built into the Lightning Skuid component? Or is this something all Lightning components come with?
2. Inputs.
a) Are inputs event parameters for other lightning components?
Lastly, can Skuid provide an updated CRM package that goes ham with all sorts of ways in which Skuid can integrate into the Lightning experience? I’ve seen demos, but the underlying architecture being accessible would be great.
Seeking deeper understanding of Lightning Component Events
+20
+131. Publishing Scope
Skuid has its own Event publishing framework, as well as publishing scopes. Currently, Skuid has four event scopes: Component, Page, All of Skuid, and Global.
(a) “All active pages and Lightning Components” = “Global” —> Skuid publishes the event to all Skuid components in all Skuid Pages, AND it publishes a Lightning “Application Event” which any Lightning Component can subscribe to using an aura:handler/
(b) “All active pages” = “All of Skuid” —> this event is published to all Skuid Pages, using Skuid’s internal event framework — Lightning’s Events framework is not involved.
(c) “Only this page” = the event is published to the current Skuid Page only, no other Skuid Pages are able to subscribe to the event.
2. Event Name
(a) For now yes these are the most commonly used events. There may be additional events available in the future.
(b) Yes, Skuid can publish ANY Lightning Application Event — so it can publish any of the standard Application events listed in the Lightning Components Event Reference.
(c) Yes, any custom Skuid Event can be published by simply knowing its name, and any custom Lightning Application Event can be published simply by knowing its name.
3. Event Parameters
You can pass in whatever key-value parameters you want when publishing an event. The data type can be whatever you want because Skuid sends the key-value parameters as JSON when publishing, so other Lightning Components that are subscribing to the “skuid:event” Event (say that fast 🙂 should be able to receive a list of records or whatever you want by deserializing the contents of the “data” param sent with the “skuid:event” event, e.g.
handleSkuidEvent : function(component, event, helper) {
var eventName = event.getParam(“name”);
if (eventName === “order.created”) {
var eventData = event.getParam(“data”);
if (eventData) {
eventData = JSON.parse(eventData);
var currentItems = component.get(“v.items”);
currentItems.unshift(eventData);
component.set(“v.items”, currentItems);
}
}
},
Event-triggered Sequences
(a) These are some standard Skuid events that we’ve designated as “subscribable” at the page level. In the future there may be additional events listed here, but any Skuid Event that’s published within a Skuid page, e.g. if a Button published a “make.me.a.sandwich” Event, could be subscribed to here at the page level.
Skuid cannot currently subscribe to other Lightning Application Events, because Skuid would have to hard-code the list of all Application Events into the Skuid package and subscribe to them all individually — obviously this wouldn’t work with customer-created Application Events. So that’s why we use the “skuid:event” Event as a shared communication channel. If customers want to publish events that Skuid can subscribe to, they need to have their components publish the “skuid:event” event.
That said, in the Millau Update 2 release, we’re adding some functionality that enables “auto-synchronization” of Skuid Models with native Lightning Components. Stay tuned for the release webinar to see more here.
(b) Inputs — these are essentially a way for you to declare the parameters that you are expecting to be published from an event, which you would like to be able to utilize in your Event-Triggered Action Sequence in the same way that you’d be able to use Inputs in a Reusable Action Sequence or a Voice-initiated Action Sequence (that’s only available on Skuid Platform, but ask about it if you’re interested 🙂 — you can do things like have dynamic Model / Field / Condition names passed in to your Action Sequences, or use input values in merge syntax {{$Input.someInputName}} , lots of awesome capabilities here.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.