Designing widgets in Reactive style
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 FRP, right? 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! Thanks a million all, -- JP Moresmau http://jpmoresmau.blogspot.com/
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 FRP, right?
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 here: https://github.com/HeinrichApfelmus/threepenny-gui/blob/master/doc/design-wi... 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 -- http://apfelmus.nfshost.com
OK thank you very much, I hadn't seen that page!! JP On Tue, Jul 8, 2014 at 10:04 PM, Heinrich Apfelmus < apfelmus@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 FRP, right?
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 here:
https://github.com/HeinrichApfelmus/threepenny-gui/blob/master/doc/design- widgets.md
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
-- http://apfelmus.nfshost.com
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
-- JP Moresmau http://jpmoresmau.blogspot.com/
participants (2)
-
Heinrich Apfelmus -
JP Moresmau