Should the API return static or live objects?

[michaelwasserman]

Let's track the overall discussion of whether the API should return static or live objects here.

Background: The existing Screen (via window.screen) is a live object. A cached Screen object (eg. var myScreen = window.screen) returns updated values after screen changes, and even updates when the window is moved across displays.

Here are some options, I'm inclined to initially pursue (C):

A) Return a "live collection" like HTMLCollection, where the length and contents of the collection can change over time. This might seem like a natural extension of the live window.screen object, but https://w3ctag.github.io/design-principles/#live-vs-static says "Objects that represent a collection that might change over time ... should generally be returned as static objects", which seems to advise against returning a collection that changes size as displays are added and removed (eg. even amid iteration).

B) Return a static-sized array of live objects. Each Screen object could reflect the latest changes, and perhaps even convey when the underlying display is disconnected, but the cached array would not be able to access Screen objects for newly connected displays. This seems attainable, but somewhat strange. It would also likely be more cumbersome for browsers to implement and might not provide justifiable utility to developers.

C) Return a static array of static objects. Developers can poll for changes, or (ideally) the API will surface events when the set of displays or their attributes change. This seems easier for developers to reason about, easier for browsers to implement, and follows the w3ctag advice. That might work okay, even alongside a live window.screen object.

Some relevant questions:

• How frequently does Screen data change?
• Do we want to expose new data that changes more frequently ( eg. Issue Dynamic properties #11 )
• Is caching Screen objects/arrays for extended periods valuable vs. re-calling getScreens()?
• Should window.Screen [eventually] return a static object if Screen Enumeration does so?

Please weigh in with your thoughts and use cases, thanks!

[michaelwasserman]

This is also related to Issue #8

[foolip]

This is a similar situation to w3c/gamepad#8 and some of the discussion there might be useful.

Some comments here.

advise against returning a collection that changes size as displays are added and removed (eg. even amid iteration).

I don't think something like HTMLCollection is a good idea, but the "amid iteration" problem wouldn't actually occur. However the list of screens is represented, the time at which it changes needs to be well defined, probably at the top of the event loop, which would be the effect of posting a task to update the screens, which would also probably match how it'd be implemented in a multi-process architecture.

A plain array of static objects as in option C seems like the least complexity and a good way to go if no use cases require more complexity. However, if that is the choice, and #24 is resolved by not returning a promise, then a sync method return an array of unchanging objects could just as well be replaced by a window.screens attribute of type FrozenArray<Screen>. The value it returns would change at the same time that that window.getScreens() would return a new value if called.

So it seems to me that resolving #24 is important for deciding on this issue.

[michaelwasserman]

The updated window-placement repo's proposed shape is settling on exposing a static sequence of static snapshots, and firing events on changes. I'm going to close this issue, but feel free to reopen it or open a new issue to provide additional feedback.