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
When deleting steps from a recipe, it looks like the deletion takes place as soon as I hit Confirm on the pop-up warning. However, there's still an active Save button at the top-right of the screen, and attempting to back out to the previous page brings up a warning about unsaved changes, even though the change has already been sent to the server. Screenshots below.
Here's my example recipe:
If I go into the Edit screen and delete a couple of steps (I'll delete 2 and 4 here), each step I delete brings up this warning:
This is good as far as it goes, in that it accurately reflects the behavior - the step is deleted as soon as I hit Confirm in this popup. I.e. if I load this recipe in the web version at this stage, I can see that the step in question has been deleted.
However, back on the Edit screen after hitting Confirm on a couple of individual step deletions, there's still a Save button in the top right. Moreover, if I back out, I get this warning about unsaved changes:
Despite the fact that the changes have been saved already (i.e. those steps no longer exist on the server.)
Also, "Abort" doesn't back me out of the editing view as I expected, but rather just aborts the backing-out action itself. There appears to be no way to back out to the view-recipe screen short of killing the app and relaunching it, at which point you will discover that those steps have already been deleted:
I guess the question becomes: should the current behavior (steps are immediately deleted on confirmation) be kept and the UI just updated to reflect that, or should that be deferred until the user hits Save? FWIW, and this is just my personal preference, I like explicit Save actions myself when the state being edited is remote. When apps send updates to the server automatically I just never feel confident that my changes have actually been saved. For one, I don't know what the latency is, how long to I have to wait before backing out of the page? If I back out too soon, will it cancel the update or will it continue in the background? For another, I frequently can't tell if updates are failing because e.g. the connection died or whatever. Having an explicit Save step makes it much more apparent to me when the state has actually been persisted, as well as providing a natural point at which an error can be displayed, if one was encountered during saving.
Just my opinion, though!
The text was updated successfully, but these errors were encountered:
Yeah, I agree on your opinion! The editing screen should definitely behave consistently.
TBH this was a lazy implementation, but I will change this when I implement step editing at the latest!
Also, "Abort" doesn't back me out of the editing view as I expected, but rather just aborts the backing-out action itself. There appears to be no way to back out to the view-recipe screen short of killing the app and relaunching it ...
I don't quite get what you mean by that. What is the "view-recipe screen"? 😅
The dialog should behave like this:
Click "Abort" if you want to continue editing the recipe
Click "Continue" to discard the unsaved changes and return to the recipe details page
You're right, I'm sorry. I think I was subconsciously interpreting "Abort" as "Abort editing" and "Continue" as "Continue editing," or something like that. I do see that if I hit Continue I can back out of the editing screen.
By view-recipe screen I just meant the screen you get to when you first visit a recipe from the home screen or search or whatever. E.g. my first screenshot above is what I would describe as the "view-recipe" screen. I don't know the internal names for these views so I'm just kind of making them up as I go along, sorry 😅
By view-recipe screen I just meant the screen you get to when you first visit a recipe from the home screen or search or whatever. E.g. my first screenshot above is what I would describe as the "view-recipe" screen. I don't know the internal names for these views so I'm just kind of making them up as I go along, sorry 😅
Ahh ok no worries I just read your message wrong 😅
I somehow read "back from the view-recipe screen" and didn't understand that.
I think its actually called the view recipe screen or something like that 😆
When deleting steps from a recipe, it looks like the deletion takes place as soon as I hit Confirm on the pop-up warning. However, there's still an active Save button at the top-right of the screen, and attempting to back out to the previous page brings up a warning about unsaved changes, even though the change has already been sent to the server. Screenshots below.
Here's my example recipe:
If I go into the Edit screen and delete a couple of steps (I'll delete 2 and 4 here), each step I delete brings up this warning:
This is good as far as it goes, in that it accurately reflects the behavior - the step is deleted as soon as I hit Confirm in this popup. I.e. if I load this recipe in the web version at this stage, I can see that the step in question has been deleted.
However, back on the Edit screen after hitting Confirm on a couple of individual step deletions, there's still a Save button in the top right. Moreover, if I back out, I get this warning about unsaved changes:
Despite the fact that the changes have been saved already (i.e. those steps no longer exist on the server.)
Also, "Abort" doesn't back me out of the editing view as I expected, but rather just aborts the backing-out action itself. There appears to be no way to back out to the view-recipe screen short of killing the app and relaunching it, at which point you will discover that those steps have already been deleted:
I guess the question becomes: should the current behavior (steps are immediately deleted on confirmation) be kept and the UI just updated to reflect that, or should that be deferred until the user hits Save? FWIW, and this is just my personal preference, I like explicit Save actions myself when the state being edited is remote. When apps send updates to the server automatically I just never feel confident that my changes have actually been saved. For one, I don't know what the latency is, how long to I have to wait before backing out of the page? If I back out too soon, will it cancel the update or will it continue in the background? For another, I frequently can't tell if updates are failing because e.g. the connection died or whatever. Having an explicit Save step makes it much more apparent to me when the state has actually been persisted, as well as providing a natural point at which an error can be displayed, if one was encountered during saving.
Just my opinion, though!
The text was updated successfully, but these errors were encountered: