Re: [whatwg/webidl] ObservableArray without assignment (#1027)

**tl;dr;** 
* I need some version of this feature
* Please don't break my already deployed code.

---

As a library implementor, if I were starting from zero today, I would't have a lot of strong opinions about what the API looked like in its final form. I would want the `adoptedStyleSheets` feature to implement against, but would abstract that away anyways. Such an abstraction could handle any property name, it could handle whether there's a setter or not, it could use add/remove APIs. It's trivial to adjust to any of these combinations while still providing the exact same ergonomics and dev experience to creators using my library (at least with the design we have).

However, we've got a library in production for 18mo or so, upon which hundreds of components have been built, used internally at Microsoft by at least several hundred engineers, deployed on major sites, that if broken will cause substantial damage. You could argue that we shouldn't have used this API until these details were locked down. At the time there were substantial benefits to doing so, and there was precedent for its use among nearly all major library authors. I had myself been using it prior to Microsoft's adoption of the API, for at least a year IIRC.

For better or worse, this is a reality we have to deal with. We are not the only ones in this situation. In light of this, I have a couple of requests:

* I need a way to reliably detect which version of this feature a given browser has currently implemented. I'd *prefer* not to have to test an API to see if it throws in order to determine the feature version.
* I need some way to prevent existing deployments from completely breaking when a browser ships the new behavior. We cannot assume that it's possible to have upgraded any deployed versions of our library in lock step with a Chromium release.

Because of these needs, at this point in time, I'd prefer to either:

1. Keep the property setter operational OR
2. Change the property name entirely

If we go with *Option 1* then I don't need to change any code. If we go with *Option 2* then my code changes are minor. I can easily feature detect without exceptions being involved. Because our existing implementation already feature detects for `adoptedStyleSheets`, in the case of a name change and a removal of the old property, our existing deployed libraries will continue to work since they will fallback to use code for browsers without `adoptedStyleSheets`. That is acceptable during an interim period while libraries are being updated.

The problem with keeping the name the same and then making the setter throw is that existing libraries which may not be upgradeable in time, will all the sudden start to fail. I'd like to avoid that most of all.

For reference, the feature detection that has been deployed for `adoptedStyleSheets` is as follows:

```ts
Array.isArray(document.adoptedStyleSheets) && "replace" in CSSStyleSheet.prototype
```

It now makes me wonder, does `Array.isArray(...)` return `true` or `false` for an `ObservableArray`? I assume `true` but if it actually returns `false` then perhaps there is no issue at all, at least for our library. It seems to me that would cause a different set of issues, perhaps more serious though...

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