Re: [whatwg/dom] `AbortController` / `AbortSignal` was updated in a somewhat breaking way (Issue #1059)

With respect to the "PRIOR" behavior of `abort()` with no argument, here's where I'm coming from and why it *feels* breaking, ergonomically, to me.

Say I'm a site author and I observe that whether I pass an argument to `abort()` or not, it doesn't change any behavior. It doesn't set a `reason`. But because of how JS works, if I access a `reason` property on the signal, I just get `undefined`. So it *feels* like the lack of providing a *reason* results in an `undefined` value for a `reason` property.

So I write a very simple function like this for my own app:

```js
function doAbort(cont,reason) {
   if (!cont.signal.aborted) {
      cont.signal.reason = reason;
      cont.abort();
   } 
}
```

In some places, I pass a `reason`, and in many others I don't. In some places, I actually intentionally pass an explicit `undefined`. Elsewhere, I can look at a `signal` instance and do checks like this:

```js
if (!signal.reason) {
   console.log("unknown reason");
}
```

I end up doing these sorts of simple checks in dozens of places throughout my app. 

I have effectively treated this `abort()` / `signal` mechanism as a simple information channel for my app to make flow control decisions. And it seems to work just fine.

When I later find out about `reason` being officially added to the spec, I'm excited and happy. I figure I can change that one function (simplify it) and skip setting `reason` (and pass it to `abort(..)`), and otherwise my information channel should work correctly.

I try that, but I'm dismayed that my whole site still seems broken. Eventually I realize it's because not only is there now a `reason` property, but even in places where I intentionally/explicitly pass it in as `undefined`, the `reason` property is not the falsy `undefined` value my intuition expected. It's a truthy object!

And when I look at the object, it's a DOMException object! Whoa, wait. So are they telling me that `reason` is essentially a required argument, because if I don't pass it, or even pass it as `undefined`, I see an exception!?

But wait, the docs (and spec!) don't really call this a "required" argument. MDN indicates it's optional. So I'm confused.

Ergonomically, if a thing has not existed before, and if it now exists but is treated as "optional", generally you just expect in places where you don't use it for it to behave as *not used*. In JS land, that USUALLY looks like a property being /remaining `undefined`.

This DOMException approach contradicts that intuition/expectation, because semantically it signals that `reason` is *required*. And I have to change every place in my code that either sends, or inspects, `reason`, to account for that new "requirement".

The DOMException doesn't *throw*, which would be even more hostile. But it does show up in my checks of `reason`, so it nonetheless feels like an exception telling me I omitted a required input.

It sure feels like a "breaking" change that now `reason` is effectively/semantically required and can't just be left/set `undefined`.

And I have a lot more code to change to adhere to this "breaking change".

----

In reality, the change in CAF to avoid setting the read-only `reason` property, only for newer envs -- but keeps setting it for older envs, as CAF has done for 4 years -- was like 5 or 6 lines of code. Not a big deal. I was relatively happy.

But then I realized the DOMException part... and that turned out to be *much* more disruptive to CAF's code. To preserve CAF's prior existing behavior (and thus the behavior sites/apps rely on), it took me 5 hours of effort yesterday and almost 200 lines of code added/changed throughout the library.

I hope maybe that perspective helps explain why this *feels* breaking even if it's not officially labeled as such.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/1059#issuecomment-1044648570
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/dom/issues/1059/1044648570@github.com>