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

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

From: Remco <remco47@gmail.com>
Date: Wed, 27 Aug 2014 09:56:25 -0600
Message-ID: <CAHpYBKzvK9QBDEsWRN+YrTuifJQkESkbCtSfeiYBEHLr+6wGCQ@mail.gmail.com>
To: Domenic Denicola <domenic@domenicdenicola.com>
Cc: Jonas Sicking <jonas@sicking.cc>, Anne van Kesteren <annevk@annevk.nl>, "public-script-coord@w3.org" <public-script-coord@w3.org>, Mounir Lamouri <mounir@lamouri.fr>, Marcos Caceres <w3c@marcosc.com>
Just a quick idea: would it be desirable to have Object.observe work on
*any* property, either through change events, or through dirty-checking?
This would mean that from a developer's perspective, it would Just Always
Work. Developers could then use the "observable" annotation in the
documentation to determine if there would be any performance considerations.

--
Remco


On Wed, Aug 20, 2014 at 9: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.
>
> 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.
>
>
Received on Friday, 29 August 2014 07:13:51 UTC

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