[Haskell-cafe] Designing widgets in Reactive style
jpmoresmau at gmail.com
Wed Jul 9 07:01:17 UTC 2014
OK thank you very much, I hadn't seen that page!!
On Tue, Jul 8, 2014 at 10:04 PM, Heinrich Apfelmus <
apfelmus at quantentunnel.de> wrote:
> JP Moresmau wrote:
>> Hello, I'm a bit confused on how to design graphical widgets to take
>> advantage of FRP design. I'm trying to do things in threepenny-gui but I
>> suppose the same question applies to any framework.
>> Suppose I want to create a "file selection widget". Currently I have a
>> function that takes a (FilePath -> UI()) function as a parameter: what to
>> do when a file is selected; my function returns the "widget", so that the
>> calling code can incorporate it in its UI. This works fine, but is not
>> Should my function take no arguments and return a (Widget,Event FilePath)
>> tuple, and let the calling code decide what to do with that event? Should
>> it be a Behavior (the currently selected file of the widget)? I *think* I
>> understand the principles of FRP, but I'm not getting what it means in
>> terms of design. What are the advantages of returning an Event and letting
>> the calling code do "on myEvent myWidget $ \file -> ..." instead of just
>> passing the handler function as a parameter?
>> I don't know if I make much sense. In any case, any pointer to non trivial
>> FRP GUI code would be good!
> I have distilled some principles for FRP widget design and wrote them down
> They are not quite complete, though, in particular the section on
> implementation details is lacking, mainly because I'm not entirely sure on
> this myself.
> In your particular example, I would use an `Event FilePath` and make it
> part of the `Widget` type, so that you have a function
> chosePath :: Widget -> Event FilePath
> The advantage of using first-class events, or FRP, in the first place is
> also briefly explained in the aforementioned document.
> From a pragmatic point of view, you could say that you certainly don't
> lose anything by offering an Event instead of registering a callback
> function. :)
> Best regards,
> Heinrich Apfelmus
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe