Order status message change causes debounced recalculation of order

[billythekid]

Description

When you change an order's status in the edit order page you can add a status message. There's something attached to this (a reactive value maybe) that recalculates the order when you're typing in it (as well as occasionally loses bits of what you're typing) with a debounce of about half a second or something.

This is an annoyance and so far as I can tell, uneccessary, though it could be for a reason I've not thought of, of course.

Steps to reproduce

1. Change the status of an order
2. Start typing in the message box, pause for a second and type some more.
3. Get frustrated that your message isn't updating nicely. <- optional. 😁

Additional info

• Craft version: Craft Pro 3.4.8
• PHP version: 7.3.10
• Commerce version: 3.0.11

[nfourtythree]

Hi @billythekid

Thank you for bringing this to our attention.

We have pushed an update that will be included in the upcoming 3.1 release. This slightly lengthens the debounce time, but also disables the textarea while the order recalculates. If a user is focused in the textarea when the recalculation start it will re-focus them in there to continue typing.

At the moment we will need to keep the update as you type idea, but might be able to look at different methods in the future.

Thanks.

[billythekid]

Heya @nfourtythree, I'm not sure if that's a fix for this really although I appreciate it changes the behaviour somewhat and should help a bit for users such as myself.

To me the bug wasn't that you were allowed to type during order updates, it was that order updates could happen while you type.

What I can envisage is a client who isn't a particularly good typist trying to update a status and not looking at the screen but watching their own fingers. The box disables as they continue typing away not looking at the screen and when they do look back up they see the end of their message is there, so assume that the whole message worked fine.

Unfortunately in this case they could well save the status with bits missing in the middle, misspellings, unfortunate profanity "added f[focus is lost]our-pack of toilet d[focus returns]uck" ;oP and so on. Their message isn't what they typed. That's a UX problem that results in a customer complaint which results in my client complaining which results in a headache. (Client induced headaches must be avoided at all times!)

Can we leave this open until it's resolved in another way that doesn't affect the textarea? Even just having to click 'save status' as an event separate from the whole order update (which could then a whole order update if you really want it) would be better?

Just adding my thoughts to this and would appreciate any behind the scenes thinking I'm not getting as to why the update as you type has to stay for status updates that arent' finished yet. I mean, the actual status of the order isn't in a savable state right? There's nothing to be lost from the history/draft/version of the order yet. Just from this end it seems like a potential real annoyance for clients but again, very aware I'm not working on all the information

I'd be happy to implement something on my end if required on a per-install basis as part of a plugin if it's unlikely to ever be fixed in some other way. (Might need some pointers in hooking into dashboard bits and pieces in Garnish though!)

[nfourtythree]

The issue that we have here is that the order isn't saved until you tell it to be saved with the update order button, it is essentially sitting as a draft in memory.

And for that instance if you add a "save status" button what should it save? As the order may have a bunch of changes that will not be included. Then if that status has an email attached this would have incorrect data in it.

Similarly, it is difficult to do it on blur/loss of focus of the textarea, as what if they type the message and then click update. There wouldn't be enough time to catch the blur before the button click. Also, blur events can be difficult to explain to a user visually.

I am happy to hear suggestions and I can definitely see your points in where there may be potential frustrations.

I think at least this current message is a step forward (even if it may not be a large step)

[billythekid]

I see the issue yeah but that does seem to be the issue with 'the current implementation' rather than some inherent problem.

Perhaps the status itself doesn't get changed with a save status button but it instead recalculates the order.

I mean what requires recalculating in the order by the status box text changing? That's all that's the issue. Why is the status box recalculating the order at all? It doesn't make sense semantically?

Nothing's really changed in that draft yet. Why not disable the save order button (with "Updating, please wait...") or similar until the recalculation of the order happens with the status change/blur event?

Explaining the onblur (this doesn't get saved until you click away) will be much easier that an ajax loop locking up their field entry to explain to a client so yeah, nothing really seems ideal here, while we think of the issue in these terms.

[nfourtythree]

Hi @billythekid

I am going to update it to not call the recalculation. There were some edge cases we discussed internally but they probably don't make as much sense.

So this will function as described, no debounce and only save when you click update order like everything else.

This should make it much better for your clients as you said 👍

Thanks!