Re: Ambient light API redesign

On Tue, Aug 26, 2014 at 5:17 PM, Marcos Caceres <marcos@marcosc.com> wrote:

>
>
>
> On August 26, 2014 at 5:00:58 PM, Jonas Sicking (jonas@sicking.cc) wrote:
> > On Tue, Aug 26, 2014 at 2:43 AM, Anne van Kesteren wrote:
> > >
> > > Perhaps something like this:
> > >
> > > var as = new AmbientSensor()
> > > var currentVal = await as.value
> > > as.onvaluechange = ...
> >
> > Would as.value just return a Promise reflecting the first reading? And
> > after that it would quickly be outdated? If so that could potentially
> > be confusing. Or does the property return a new, immediately resolved,
> > Promise every time that onvaluechange fires?
>
> We are actually discussing this on Twitter right now. It seems you don't
> need the promise. The constructor causes the subscription to the sensor,
> and then you can potentially just observe `.value` until it gets updated.
> It's initially set to null. IIUC, it means you don't need onvaluechange
> either. For very chatty sensors, an polling option might be passed with the
> constructor to control how often updates happen.
>
>
> If you don't want to subscribe (by creating an instance), you can do
> something like:
>
> ```
> AmbientSensor.getCurrentValue().then(data => ... )
>
> ```
>
> Rick is capturing a lot of this here:
> https://gist.github.com/rwaldron/5016343
>
>
I just updated this to reflect the additional points that came from the
conversation.

Rick