docs: adding discussion of 'cancelation' behavior, other improvements…

… for clarification

README.md

@@ -22,7 +22,9 @@ button.addEventListener("click",() => throttler(onButtonClick));
 
 ## Overview
 
-The main purpose of **Scheduler** is to provide [debouncing and throttling](https://css-tricks.com/debouncing-throttling-explained-examples/) controls for managing async task scheduling. Both scheduling schemes reduce how many repeated calls to a single function will be processed, over a defined interval of time, but use different strategies for determining when to schedule those calls. And both strategies may operate in two forms: *leading* and *trailing*.
+The main purpose of **Scheduler** is to provide [debouncing and throttling](https://css-tricks.com/debouncing-throttling-explained-examples/) controls for managing async task scheduling.
+
+Both scheduling schemes reduce how many repeated calls to a single function will be processed, over a defined interval of time, but use different strategies for determining when to schedule those calls. And both strategies may operate in two forms: *leading* and *trailing*.
 
 ### Throttling
 
@@ -32,11 +34,19 @@ With leading throttling, the initial call is processed immediately, and any subs
 
 ### Debouncing
 
-Debouncing resets the delay interval with each attempted call of a function, meaning that the delay of processing an initial attempted call will continue to increase (unbounded), with each subsequent call attempt during the defined interval.
+Debouncing resets the delay interval with each attempted call of a function, meaning that the delay of processing an attempted call will continue to increase (unbounded), with each subsequent call attempt during the defined interval.
+
+With leading debouncing, the initial call is immediately processed, after which subsequent calls are debounced; once a full interval transpires without attempted calls, the most recent call is processed. With trailing debouncing, no initial call is processed, and every call is debounced.
+
+Debouncing *might* effectively delay a function call indefinitely, if at least one call attempt is made during each defined interval of time. This is usually not preferred, so you can set an upper bound for the total debouncing delay, after which the most recent call will be processed and the debouncing interval reset.
 
-With leading debouncing, the initial call is immediately processed, after which subsequent calls are debounced; once a full interval transpires without attempted calls, the most recent call is processed. With trailing debouncing, no initial call is processed.
+### Canceling
 
-Debouncing could effectively delay a call being processed indefinitely, as long as at least one call attempt is made during each defined interval of time. So, you may optionally set an upper bound for the total debouncing delay, after which the most recent call will be processed and the debouncing interval reset.
+Any throttled or debounced call that has not yet happened yet, may be canceled before it is processed.
+
+For example, you might debounce the initial display of a spinner (e.g., 500ms) for an async task that can vary in duration (like a network request); debouncing prevents the spinner from flashing visible and then being hidden very quickly -- if the network request finishes very quickly. But if the network request finishes even faster than the 500ms, you can cancel the scheduled display of the spinner.
+
+**Tip:** Debouncing the spinner showing, as described, still risks a potential UX hiccup. The network request might finish shortly after the debounce interval delay has transpired, which still quickly flickers the spinner. And this gets even worse if a subsequent async operation might be triggered (debounced) right after, such that the user might see a series of spinner flickers (on and off). One solution is to *also* debounce the canceling of a previous operation's debounce. In other words, the spinner might delay in being shown, but once shown, delay in its hiding. This approach [is essentially a debounced toggle (see **byojs/Toggler**)](https://github.com/byojs/toggler).
 
 ## Deployment / Import
 
@@ -88,6 +98,8 @@ The API provided by **Scheduler** is a single function -- the default export of
 
 This function receives one to three arguments, to initialize a scheduler instance -- represented by another function as its return value -- using either [the throttle strategy](#throttling) or [the debounce strategy](#debouncing).
 
+### Configuring *unbounded* debouncing
+
 To initialize an unbounded-debounce scheduler (in *leading* or *trailing* mode):
 
 ```js
@@ -100,6 +112,8 @@ var debouncer2 = Scheduler(250,Infinity,/*leading=*/false);
 
 **Note:** The second argument represents the upper bound for total debouncing delay; `Infinity` (default) allows unbounded debouncing delay.
 
+### Configuring *bounded* debouncing
+
 To initialize a bounded-debounce scheduler (in *leading* or *trailing* mode):
 
 ```js
@@ -110,6 +124,8 @@ var debouncer3 = Scheduler(250,400);
 var debouncer4 = Scheduler(250,400,/*leading=*/false);
 ```
 
+### Configuring throttling
+
 To initialize a throttle scheduler (in *leading* or *trailing* mode):
 
 ```js
@@ -122,26 +138,47 @@ var throttler2 = Scheduler(250,250,/*leading=*/false);
 
 **Note:** As shown, the throttling strategy is activated by passing the same value for the first two arguments (delay and upper-bound).
 
-----
+### Scheduling tasks
 
-Once you've setup a scheduler instance, you can schedule function calls by passing the (same) function value in (each time):
+Once you've setup a scheduler instance, you can *schedule* repeated function calls by passing the (same) function value in (each time).
+
+For example, with `debouncer1` (as configured above):
 
 ```js
-debouncer1(someFunc);
+debouncer1(someTask);
 
 // later (but within 250ms of previous call)
-debouncer1(someFunc);
+debouncer1(someTask);
 
 // later (but within 250ms of previous call)
-debouncer1(someFunc);
+debouncer1(someTask);
 ```
 
-In this snippet, `someFunc` will only be called once (with no arguments), ~250ms after the last call (within the interval) to `debouncer1()`.
+In this snippet, `someTask` will only be called once (with no arguments), ~250ms after the last call (within the interval) to `debouncer1()`.
 
-The same scheduler instance can be used for debouncing/throttling as many different functions as desired, assuming the timing settings should apply for all of them.
+You can share the same scheduler instance can for debouncing/throttling as many different functions as desired, assuming the same timing settings should apply for each of them.
 
 **Warning:** The internal tracking of repeated and async scheduled calls is based on function reference identity. If you pass an inline function expression (such as an `=>` arrow), the function reference will be different each time, and will be treated as entirely separate functions -- thereby defeating the debouncing/throttling. Make sure to use the same stable function reference for all scheduling-related invocations of the scheduler instance function.
 
+### Canceling a scheduled task
+
+The scheduler instance (e.g., `debouncer1` from above) returns yet another function, which is a *canceler*:
+
+```js
+var canceler = debouncer1(someTask);
+
+// later (but within 250ms of previous call)
+canceler();
+```
+
+If `canceler()` (as shown) is called before the debounced `someTask()` function is actually called, that debounced scheduling will be canceled. The same *canceler* will be returned for all subsequent `debouncer1()` calls **within the same interval**:
+
+```js
+debouncer1(someTask) === debouncer1(someTask);      // true
+```
+
+Since the *canceler* function is stable (within the same interval), it's safe to preserve a reference to that function, to use at any time during that interval. Once the interval transpires, the function becomes *dead* (no-op), and should be discarded.
+
 ## Re-building `dist/*`
 
 If you need to rebuild the `dist/*` files for any reason, run:

package.json

@@ -1,7 +1,7 @@
 {
 	"name": "@byojs/scheduler",
 	"description": "Throttle/debounce scheduler",
-	"version": "0.0.0-20240903035700",
+	"version": "0.0.9",
 	"exports": {
 		"./": "./dist/scheduler.mjs"
 	},