Why would adding a pause to the Page is Loaded workflow result in two improvements?
The page loads noticeably faster.
An action that is otherwise skipped is executed as it should be.
Why does a pause speed things up and make them work as they should???
The app has a page that loads an Action thing (think "To Do") along with some other associated things.
One "trick" in the app is to set a page-level custom state, "isDirty", to indicate when any element on the page has changed such that it should be written to the database. The state isDirty is used in conditional formatting of buttons to cue the user that she should not leave the page without saving or at least thinking about why to abandon unsaved changes.
It looks like this:
To the user, it looks like this:
The Leave Unchanged and Home buttons are dim and have a tooltip indicating that changes should be saved. It’s up to the user to decide to click these buttons without saving the changes.
The initial value of isDirty is Yes.
There is a fair amount of work done in the Page is Loaded workflow to set things up.
One of the last actions of Page is Loaded is to set isDirty to No. As a result, all buttons should be fully rendered and available.
The Problems
The page takes an inordinately long time to load. Something on the order of four to five seconds.
Nearly all the time, it appears that isDirty is not set to No as it should be in the Page is Loaded workflow.
A Solution?
Add a pause of 100ms preceding the action to set isDirty to No.
Page load is noticeably faster (but still slower than I can believe it should be.)
The isDirty state is properly set to No.
Here’s a link to the app.
I don’t know how to improve the setup for people to look at the app, so here’s what I think you need to do. I hope the following makes sense and is appropriate for posting here.
Run as my user, which you’ll see is the only one in the Users table.
In the index page, click on the name of any Action.
@laurence one approach is to gradually remove bits to make a minimal app to show the problem.
For example, does the pause make things faster:
without the conditional terminates?
without the custom event triggers?
without setting any custom states?
I couldn’t see any page load step that sets isDirty to yes.
I’ve cloned action-detail to orig-action-detail, and to misha-action-detail, which I’ll fiddle in.
I set isDirty default to yes on misha-action-detail, and on page load the behaviour is: for about half a second the Home and Leave Unchanged buttons are dimmed, then go to bright.
I removed the pause from the workflow, and on page load the behaviour is: the Home and Leave Unchanged buttons stay dimmed.
I suspect that the default values of the other custom states are also important, and didn’t get copied over from your main app? Is this another bug to raise?
EDIT - I did a quick test, custom state defaults seem to copy over.
Can you set the correct custom state defaults to reproduce the behaviour?
Feel free to remove the additional pages.
I’ve found that these timing issues (that are seemingly fixed by changing duration of pauses, inserting terminate actions, changing delay of api scheduling, etc.) often point to situations where I have conflicting actions trying to modify the same thing.
For example, I had an autobind field that also triggered an event on change. Depending on conditions, this could setup instances where the thing being modified by the autobind, was modified a second time which could take several seconds to complete, or bug out.
Another area this happens in, is having popups on a page with visible elements that have when changed events. If you edit data in that pop-up that impacts those events, multiple updates start conflicting.
Solutions include:
Carefully considering all visible events (hidden do not seem to matter) when modifying things and making sure you modify a thing in only one place at a time.
Hiding conflicting elements when not in use.
The pause fix can help, but feels less reliable to me as the overall speed for the user can vary.
At any rate, it makes sense to me that a pause can make workflows faster, because when conflicts exist, they can explode the duration.
You’re right, @mishav. The default of True is something I did in another version of the app. Originally, the state didn’t have a default value. The behavior was the same as it is with the default value.
The sample app I shared now has the default value of True.
The sample I shared publicly is a scaled-down version of what should be a full-blown productivity app, i.e. a to-do list on steroids.
The sample is just focusing on Actions, i.e. to-dos, associated with projects. When completed, it will be far more sophisticated than what I’m sharing here.
