search

WICG / web-preferences-api

The Web Preference API aims to provide a way for sites to override the value for a given user preference (e.g. color-scheme preference) in a way that fully integrates with existing Web APIs.
https://wicg.github.io/web-preferences-api/
Other
41 stars 2 forks source link

Why are we using Promises here? #6

Closed tabatkins closed 10 months ago

tabatkins commented 10 months ago

I'm not certain why Promises are involved here. I understand that these are writing to what is likely an async storage, but that doesn't necessarily have to mean that the author-facing API is async, especially if it's solely used to track the overrides themselves.

That is, setting navigator.preference.colorScheme = "dark"; can be done synchronously; the preference object immediately reflects the "dark" value. But it will affect the actual MQ asynchronously, and authors can listen for that change with an appropriate async API.

This has several benefits:

  1. It avoids race conditions with several things overriding the same preference. Each thing will be able to see the preceding override already.
  2. It lets us give an immediate error if the value is set incorrectly, rather than requiring the author to handle a promise rejection.
  3. It lets us cut out the entire method-based interaction mode, letting us just use attributes (as in #4).

If we want to allow authors to see the "real" value of the MQ, we could add an async method to this API. We could probably just bake it into the getSupported() method, adding a currentValue attribute, since that method is already async.

lukewarlow commented 10 months ago

Thanks for the feedback! I've hopefully addressed the issues you've raised and have opened #8 to discuss the iframe behaviour in more detail.