[wp-trac] [WordPress Trac] #38365: Selecting another theme feature filter requires to wait until a previous request has finished

[WordPress Trac]

#38365: Selecting another theme feature filter requires to wait until a previous
request has finished
-------------------------------------+-----------------------------
 Reporter:  ocean90                  |       Owner:
     Type:  defect (bug)             |      Status:  new
 Priority:  normal                   |   Milestone:  4.7
Component:  Customize                |     Version:  trunk
 Severity:  normal                   |  Resolution:
 Keywords:  needs-patch ui-feedback  |     Focuses:  ui, javascript
-------------------------------------+-----------------------------

Comment (by folletto):

 Thanks for the tickets, which confirm what I was mentioning about a button
 not being a solution to the issue.

 Also, the issue I see on #36202 seems similar to what I'm saying here:
 there's a discussion on debounce, but not on queuing. Debounce is an
 optimization on top of queuing, not in substitution of it, because as you
 said without queuing just the debounce will still cause errors on one side
 or the other of the delay.

 > Basically, there's no "proper" way :) An arbitrary delay would fit for
 some users, and wouldn't for others.

 IMHO there's a proper way, which is both queue + debounce. The ''queue''
 addresses the issue of multiple requests (and we should discuss the logic
 about it) and ''debounce'' optimizes the requests the queue is going to
 do.

 Let's put the "delay" point on the side for a moment, since it's not the
 primary issue here. The issue is that the Ajax call is blocking, thus: we
 need to fix the queuing first.

 ----

 So, here's '''Draft 1''' of the logic:

 * Filter toggled → the request is done with a debounce to 500ms (we can
 tweak this once we test it live)
 * If the user toggles another filter within the threshold (500ms), then
 debounce takes care of it.
 * If the request is sent, and the user toggles another filter during the
 request, the new call is queued (1).
 * If the request is sent, and the user toggles another filter during the
 request, the new call is queued (2).
 * Once the request is returned, the UI updates, and the next request in
 the queue gets processed (1)

 This is probably not ideal on slow connections due to the implied delay of
 multiple checks stacking up, so we could get around it with a "wait slot"
 (or "queue of one", there's probably a better name but my memory is
 failing me) that holds always the last available request. '''Draft 2''':

 * Filter toggled → the request is done with a debounce to 500ms (we can
 tweak this once we test it live)
 * If the user toggles another filter within the threshold (500ms), then
 debounce takes care of it.
 * If the request is sent, and the user toggles another filter during the
 request, the new request is added to the wait slot.
 * If the request is sent, and the user toggles another filter during the
 request, the old wait slot request is discarded, and the new request is
 placed in the wait slot.
 * Once the request is returned, the UI updates, and whichever is in the
 wait slot gets sent.

 Thinking about it, always reflecting on potential slow connections, the
 logic could maybe be even simpler if we can cancel the running request.
 This optimizes for responsiveness at the risk of more API requests.
 However, the debounce should avoid a too high ratio of these, so it might
 be good. '''Draft 3''':

 * Filter toggled → the request is done with a debounce to 500ms (we can
 tweak this once we test it live)
 * If the user toggles another filter within the threshold (500ms), then
 debounce takes care of it.
 * If the request is sent, and the user toggles another filter during the
 request, the request is cancelled and the new request is sent.
 * If the request is sent, and the user toggles another filter during the
 request, the request is cancelled and the new request is sent.
 * Once the request is returned, the UI updates.

 Whichever we decide here, should be useful also on the other ticket, so
 maybe we can think of it of a more general pattern that can be reused.

 I hope it helps. :)

--
Ticket URL: <https://core.trac.wordpress.org/ticket/38365#comment:11>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform