reactive-banana icon indicating copy to clipboard operation
reactive-banana copied to clipboard

Pull-based behaviors?

Open avieth opened this issue 9 years ago • 3 comments
trafficstars

The motivation: when doing DOM programming we sometimes wish to deal with the dimensions of elements. It seems natural to say that there is a Behavior Rect for an element's bounding client rectangle. But how to construct such a thing?? We would need an event to give the changes, but the DOM doesn't supply that, and polling it would probably grow prohibitively expensive. Why not compute it on-demand?

This patch defines fromPull :: IO a -> MomentIO (Behavior a) to produce pull-based behaviors. Ideally, the IO would run at most once per evaluation of the network. In this implementation, it's run at least 0 times. I have a feeling I'm doing something horribly wrong in newLatchIO.

What do you think? Good idea? Not so good? Consider this a feature request with code attached.

avieth avatar Mar 31 '16 21:03 avieth

Sorry for taking so long to have a look at this, and sorry that I can only triage this at the moment.

I think the idea is interesting and useful.

Note that the implementation of fromPull does not need a LatchWriter, the purpose of the latter is only to connect a Pulse and a Latch. In this case, everything can be implemented within the Latch record. The reason why your code does not work is probably that the _seenL value is not updated.

I think a correct implementation would simply be to apply cachedLatch to an IO action (lifted into the EvalL monad).

HeinrichApfelmus avatar May 17 '16 21:05 HeinrichApfelmus

Could this concept simply replace fromPoll? fromPull has the same type signature, and pulling only wen necessary seems preferable to polling on every input event.

mitchellwrosen avatar Aug 29 '17 18:08 mitchellwrosen

Note that the implementation of fromPull does not need a LatchWriter, the purpose of the latter is only to connect a Pulse and a Latch. In this case, everything can be implemented within the Latch record. The reason why your code does not work is probably that the _seenL value is not updated.

I think a correct implementation would simply be to apply cachedLatch to an IO action (lifted into the EvalL monad).

I believe if you implement this feature only with cachedLatch, the IO action will be performed as many times as the latch is evaluated. For example,

b <- fromPull (print 5)
e1 <- b <@ someEvent
e2 <- b <@ someEvent

reactimate (print 10 <$ e1)
reactimate (print 20 <$ e2)

Here, ideally the action print 5 would only be performed once. But because it's sampled by two different events, this would print

5
10
5
20

when someEvent fires.

mitchellwrosen avatar May 27 '18 18:05 mitchellwrosen