Idea: OK/Cancel Message as an action

Currently there is the ability to display a message and block the UI as an action. It would be nice to have the ability to have an “OK/Cancel” message that would block the UI, display a message, then give the user the option of clicking OK or Cancel. For example: “Are you sure you want to commit these changes to all 140 Contacts?” OK or CANCEL. If the user presses Cancel, it would abort any actions after the OK/Cancel Message Action

Hey Raymond - If you haven’t already, vote for this Having the ability to create custom actions would give us page builders the ability to do anything we need without Skuid having to add in all the things we want to the core product :slight_smile:

Barry, I’m having Deja vu. I think I may have posted this idea (or something similar) before and I think you may have suggested the same post. That or I’m losing my mind. So help me understand how this works. You would write a JavaScript snippet and then Skuid would display it as if it were a declaritive action so that you could update the properties declaratively instead of updating the JavaScript properties directly?

Hey Raymond -

Skuid actions are just blocks of javascript code that get “registered” in the underlying framework so that they appear in the list of actions in the builder.  What “Custom Actions” would offer is the ability for people like you and I to write those same blocks of code and register those with the underlying skuid framework so that they appear in the list as well.  The block of code has several key items including which properties are available.  Let’s take the “Show message and block UI” action for example.  That “block” of code has properties that it exposes like “what’s the message” and “how long should I stay on the screen for.”  It also has code that executes the actual code required to make the message appear.  Custom actions would work just the same.  They aren’t snippets per se, but similar.  They are more akin to custom components since there is metadata and code associated to them.  For the example in the video, the “Confirm Dialog” custom action has 4 properties (title, message, yes button, no button) and a block of code that gets executed during runtime to display the dialog based on those property values.

Being able to build and register custom actions provides page developers way more flexibility to accomplish repetitive tasks with a single block of code without having to wait for that specific “need” to be added to the core product.  The Skuid team is awesome but there is no way they can keep up with all the feature requests and often times, features that you or I might need, no one else needs so, understandably, there isn’t enough value in Skuid developing that particular type of action.  Custom actions would solve for all this.

Hope this helps!

I see where you are going with this… This isn’t something I see myself utilizing much, but I can see how it would be helpful to those who write code and use similar actions over and over in slightly different scenarios. I can also see it being useful in the community setting as it would make it easy to share custom actions between on another. It seems like this structure would also make it easier for Skuid to add additional actions to the menu by utilizing code generated by the community. Maybe under an “advanced actions” header.

Exactly.  In the video I provide a little glimpse in to how I would see it working.  In short, the custom actions would appear under “Additional Actions” at the bottom of the action drop-down list - no need for a 2nd separate section :slight_smile:

Got ya… I was differentiating between custom actions you dream up for specific uses and more general “advanced actions” that Skuid would make available to users by default. I’m good with “Additional Actions”. It’s your idea… I’m just tagging along for the ride!

lol.  I see what you mean and that makes a lot of sense.  Ok, you convinced me, “Additional Actions” for skuid additional actions and “Custom Actions” for custom registered actions :slight_smile:  Actually, could get even more advanced and have a section in the list for each “action pack” that registered custom actions.  So, you’d have “Additional Actions”, “Raymonds Actions”, “Barrys Actions”, etc.  That would be helpful - similar to the way component packs display in the toolbox.

Now, if only they were officially supported by the core framework, think of the fun we could have! :slight_smile: