W3C home > Mailing lists > Public > public-script-coord@w3.org > July to September 2014

Re: Object.observe()able properties on the web platform

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 20 Aug 2014 08:35:09 -0700
Message-ID: <CAAWBYDA_Zs42Tv5o-zdDH5KwAdS6URjL5WqHoDQ=jPUE1OA+jg@mail.gmail.com>
To: Domenic Denicola <domenic@domenicdenicola.com>
Cc: Jonas Sicking <jonas@sicking.cc>, Anne van Kesteren <annevk@annevk.nl>, Mounir Lamouri <mounir@lamouri.fr>, Marcos Caceres <w3c@marcosc.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>
On Wed, Aug 20, 2014 at 8:06 AM, Domenic Denicola
<domenic@domenicdenicola.com> wrote:
> [Spawning new thread on public-script-coord; whatwg to bcc]
>
> From: whatwg <whatwg-bounces@lists.whatwg.org> on behalf of Jonas Sicking <jonas@sicking.cc>
>
>> On Wed, Aug 20, 2014 at 1:33 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
>>> On Wed, Aug 20, 2014 at 10:29 AM, Jonas Sicking <jonas@sicking.cc> wrote:
>>>> FWIW, the web platform sorely needs a construct for "readonly state
>>>> variable + event whenever the state changes". I.e. some form of
>>>> observable which remembers the last produced value. I had hoped the
>>>> Streams would get us closer to that, but the current definition seems
>>>> to be too different.
>>>
>>> Isn't that Object.observe() with custom records produced by the
>>> specific object you are defining for the property you want to enable
>>> this for (in this case held, it seems like)?
>>
>> That's a good question. It'd be awesome if Object.observe() solved this problem for us.
>>
>> One thing that I'd worry about is that it'll be hard for authors to know which properties are observable, and which ones aren't. But maybe that's something we can live with.
>
> Object.observe() is in my mind exactly what solves this problem.

Agree, though you know my thoughts on the utility of designing an
"object stream" or "observable" class.  In my previous proposal on my
blog, I had a static method on the class which basically did an
Object.observe for you and turned it into an object stream
automatically.

> Remember that it doesn't work out-of-the-box for getters. And, most DOM properties are clearly "getter-like" from an author perspective: i.e., besides that being their actual observable implementation, they also are usually getting some underlying part of the system that is not otherwise accessible; it is hard to imagine them as simple data properties which anyone can toggle. So IMO authors will bring the same expectations to DOM objects they do to regular objects: getters will be sometimes observable, but only if the implementation of that object has taken the time to make them so.
>
> I think it would be a good idea to start working on additions to WebIDL to mark properties as observable, so that Chrome at least can start firing change records for them. I imagine this propagating to developer docs (MDN etc.) as some kind of "observable" annotation that authors will come, in time, to learn means they can Object.observe() that property.

Is this necessary?  What prevents us from simply defining that DOM
objects have all properties observable, even the getter-like ones?

~TJ
Received on Wednesday, 20 August 2014 15:35:55 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:22 UTC