Re: [FileAPI] FileReader.abort() and File[Saver|Writer].abort have different behaviors

On Mon, Oct 3, 2011 at 6:00 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> Unfortunately I suspect wanting to call open from event handlers is a
> pretty common use case. Here are two use cases:
>
> 1. In case of a network error, let the onerror handler retry the request.
>
2. Implementing a auto-complete UI backed by data stored on the
> server. Any time the user hits another character, abort the current
> request and perform a new request with the newly typed value.
>

These can be handled trivially by wrapping in a timer.  This is a basic
platform concept, an approximation of "queue a task" so common in specs.

(#2 isn't actually a problem, since it's an event from a different
source--it's only recursing back into the same XHR/FileReader/etc. object
from its own events that causes ugliness.)

For example if you're implementing a progress bar, it would be very
> easy to make the mistake of hiding the progress bar from "loadend" and
> showing it in "loadstart". In the two use cases above, that would
> result in the progress bar not showing during the second load. I'll
> leave as an exercise to the reader how to avoid such a bug ;-)
>

This shouldn't be a "mistake"--it's the natural, obvious way to use these
events.  You shouldn't have to worry about receiving two loadstarts in a
row, or two loadends in a row, or missing loadends, depending on what object
is firing the event, how its API is being used, or where your event listener
is in the event handler list.

Needing to use setTimeout in some cases is a tiny price to pay, to avoid
having to worry about that mess and keep these events straightforward and
predictable.

-- 
Glenn Maynard