[LRUG] Double submit

[Tom Stuart]

On 24 Apr 2015, at 16:12, Andrew Stewart <boss at airbladesoftware.com> wrote:
> I hadn't thought of debouncing the side-effects instead of the requests.  Presumably one would have to explicitly code this in wherever necessary.

Yes, but that’s arguably a benefit: a little more work in exchange for a lot more robustness. It may make more sense for “we don’t send two identical emails within 5 seconds”, “we don’t create two identical orders within 5 seconds” etc to be inherent constraints of the domain that are tidily encapsulated by our model of it, rather than incidental properties that emerge indirectly from the current behaviour of the UI.

> In contrast a middleware approach could apply to all POSTs.

In theory yes, but what should happen in practice when a duplicate POST is detected? I can’t think of a generic solution that gives a good user experience. (“Validation error: form already submitted” doesn’t count.)

>> ... in the event of a double-click, it's the second submission that the user will actually see.
> That seems like a fairly crucial point – does it always hold?  No matter whether we somehow ignore the second POST or debounce its side-effects, we want the user to see the result of the first POST.

The point of debouncing is that, to an external observer, the first and second POSTs have the same result; if you debounce “create an order”, then two calls in quick succession both return the same order, so the visible result should be the same regardless of which response you see. (In practice it might take some effort to make this work with the volatile parts of an Active Record’s state, e.g. dirtiness.)

Cheers,
-Tom