search

aarongustafson / pwa-widgets

Playing with some ideas around widget definitions for PWAs
24 stars 0 forks source link

The `WidgetClient.id` is readonly #5

Closed tomayac closed 2 years ago

tomayac commented 2 years ago

If WidgetClient.id is supposed to be similar to WindowClient.id, then it's readonly and will be set by the browser to an opaque string:

Screen Shot 2022-02-04 at 17 23 29

Were you maybe thinking to model this analog to the manifest's id member, which is writable?

aarongustafson commented 2 years ago

Yes, my intent was for it to be dev-defined like the Manifest as it will be necessary for orchestrating updates to the correct widget (especially if you have multiple). Having a unique id, per widget, that is known to the developer should make that process more predictable and faster (no need to enumerate Widgets). If the implementation concern is potential collisions, I think there can be an internal process for remedying that by generating an system-level identifier that combines the widget id with the Manifest id (e.g., "https://example.com/" + "inbox" or similar).

aarongustafson commented 2 years ago

Tucking into the SW spec (and its inheritance from HTML) a bit more, it looks like the Client id originates from HTML’s environment concept which is the readonly, browser-directed piece. Assuming the WidgetClient interface inherits from Client in the same way WindowClient does, it might make sense to pivot slightly to map it to the Notification tag. I still think id makes more sense from a nomenclature standpoint, but mechanically the tag concept is more in line with what I’m looking for (a way to disambiguate Widgets). The process for updating a Notification (which you first have to find by its tag) is a little clunkier than I’d like for this, but I don’t think everything needs to be modeled 1:1 on Notifications either.

More on this soon…

tomayac commented 2 years ago

Thanks for considering my comment, tag seems like a good compromise and avoids misunderstandings.