You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This would be a straightforward code change to do (in workflow) page transitions while asynchronously saving the submission. This differs from the current situation, where the submission is persisted, then the transition occurs, potentially causing a user noticeable delay in page transitions.
This is potentially related to an anomalous transition behavior where sometimes a workflow step will flash quickly before transitioning correctly to the next page.
While the code change is straightforward, we need to be sure that this does not have any negative impact on subsequent routes.
Note: I wouldn't think that subsequent routes would be effected, as the operation only persists changes that already exist in the client Store.
The text was updated successfully, but these errors were encountered:
Lines like this are responsible for this behavior. We could take this opportunity to refactor the submission saving code perhaps to a Mixin so this saving code is not repeated as much as it is currently.
On the surface this is a simple fix. A quick experiment of simply pulling the transition out of the save Promise resulted in much faster page loading, but I am not convinced that it would the subsequent page would load correctly consistently.
Some workflow steps rely on data persisted on the Submission in order to render the UI correctly. We need to wait for the save to complete either before or after the transition.
We could potentially observe the Submission (Ember Data) property isSaving and only trigger the appropriate service calls when the submission.isSaving is false. This way we could transition to the next workflow step and update the model when the submission save is done
This would be a straightforward code change to do (in workflow) page transitions while asynchronously saving the submission. This differs from the current situation, where the submission is persisted, then the transition occurs, potentially causing a user noticeable delay in page transitions.
This is potentially related to an anomalous transition behavior where sometimes a workflow step will flash quickly before transitioning correctly to the next page.
While the code change is straightforward, we need to be sure that this does not have any negative impact on subsequent routes.
Note: I wouldn't think that subsequent routes would be effected, as the operation only persists changes that already exist in the client Store.
The text was updated successfully, but these errors were encountered: