This is a bug or a nuisance.
I have a button on a page. The button has 3 actions. I expect the actions to occur in the sequence specified:
BLOCK UI WITH MESSAGE
RUN JAVASCRIPT SNIPPET
SHOW MODAL
The Message is not displayed until AFTER the snippet runs AND the modal is displayed. (For what it’s worth, the modal contains only a Page-Include component.
The purpose of the BLOCK UI WITH MESSAGE action is to have the user WAIT while the snippet runs. The snippet includes a “skuid.$.unblockUI();” statement to release the UI.
IN ADDITION, the Page-Include is basically a Calendar component, which loads VERY SLOWLY in V2. I now want to bypass the unblockUI() function in the snippet and execute it instead when the calendar
model is queried. I’ve added an action to the model, but that action runs TWICE, although the model is only supposed to be queried by the calendar. The simple “unblockUI()” snippet now includes logic to determine if the last model condition came from the composer or the calendar (sourceendlimit). But if the BlockUI-Message doesn’t get displayed at the right time, the behavior is hard to predict.
Hello,
It is slightly hard to understand since there seems to be many things happening.
Let me try to help with few
Block UI is not displayed in timely fashion:
- I’m uncertain how Skuid Action block UI exactly works, but
- if JQuery.blockUI(.) is ran via JS that might take few MS in the background to run before UI is blocked.
- It is like an Aync process, but you cannot use await.
- If block UI doesn’t appear after 500ms or few seconds then I would question if your JS is taking up all the processing power.
- I’m also unsure why your Block Ui is displayed at all if snippet unblocks it.
- An interesting test would be disabling JS Snippet action, and seeing if Block UI still only appears after modal dispalyed
Model actions executed twice
- More required event is triggered when model is required, AND
- the event is also trigger when the model loads (which is when page loads).
- Workaround:
- have have an action sequence that is triggered on page load which updates a variable or a value in model, e.g. PageLoaded = True.
- Add logic branch to model actions that checks for this value
JS
- Your message didn’t indicate what your JS does.
- If there are ASYNC functions executed in your JS snippet and they are not handled with Promises/async-await then your modal will start loading before JS snippet finishes.
Hope this was somewhat helpful
Best,
Lukas
Okay, thanks.
The UI block is applied by a skuid action. The javascript takes awhile to run (60-90 seconds). It calls 8 apex processes with “var result = sforce.apex.execute().” With console.log messages between each process, we see the js step through the script slowly. At the end is the unblockUI().
If we disable the js, the action block is displayed before the modal.
Maybe JQuery.blockUI() in the script will duplicate the Version 1 behavior.
sforce.apex.execute() is the cause of your issue. As mentioned before BlockUi() is not executed immedietly, therefore before it finishes executing sforce.apex.execute() takes up all the resources, and blockUI doesn’t finish until apex returns.
My suggestion would be add artificial sleep/wait of (maybe) 100ms to allow blockUI() to execute before apex is called. It’s hard to say how long it should be since I could not find explanation of why blockUI behaves like that (it’s async but you cannot use await).
Potentially, the artificial sleep/wait could be 10ms, it’s kind of ‘try and test it’, determine the wait at your own risk. If it’s too short you will might sometimes the behavior you see now, if it’s too long you are increasing how long the entire process takes.
I don’t know what is delaying what, but my solution is to wrap the javascript code in a setTimeout() function to delay it by 500ms. That allows the Block UI With Message action to have the intended affect. The script still has an unBlockUI() at the end to release the interface.
The page-include calendar also uses a skid-page-rendered event to run another BlockUI With Message action with an 8-second timeout to allow the very slow V2 calendar to populate.
These timings work in a test environment; I cannot guarantee them for production.
