[elm-discuss] Re: Inter triplets communication.
This is a very educational discussion! Thank you for sharing links and examples. As perhaps a minor point, I believe the elm-sortable-table does NOT belong in the list of "encapsulated state", "components", "triplets". It does have a State type defined. But a notable difference with various other examples is that sortable-table does NOT have its own Msg or update function. I've always seen the sortable-table as an example of how customizable and feature-rich you can get, *without *encapsulating an inaccessible local state. React + flux lingo would be a *pure *component. -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[elm-discuss] Re: Inter triplets communication.
Not only me asking this questions. https://groups.google.com/forum/#!msg/elm-discuss/u3J2eSThkjw/4FT3p50uBAAJ and http://blog.jenkster.com/2016/04/how-i-structure-elm-apps.html On of the interesting solutions https://github.com/folkertdev/outmessage another http://package.elm-lang.org/packages/prozacchiwawa/effmodel/2.0.0/ and elm-parts -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[elm-discuss] Re: Inter triplets communication.
On Monday, November 28, 2016 at 2:38:13 PM UTC, Rupert Smith wrote: > > On Monday, November 28, 2016 at 2:01:34 PM UTC, sergii.k...@zalando.de > wrote: >> >> I feel it will be too messy to keep all this inter-triplet logic here. Is >> there a better way? Maybe something similar to pub/sub or I'm >> fundamentally wrong here? >> > > I've pulled out a message channels pub/sub implementation. > In view of Richard's comments, you should ignore my pub/sub suggestions for now. I just assumed you had a genuine need for 'out messages' and communication between child modules in a nested TEA - rather than that you should consider restructuring your code to avoid overly modularizing it in the first place. You may be wondering how your login 'widget' can be re-used, as it not only has to display a button but also produce events in reaction to the user clicking the button: loginButton : msg -> Html msg loginButton tagger = button [ onClick tagger ] [ text "Login" ] Is a re-usable button that can be set up to trigger whatever Msg you pass in as an argument - usually called a 'tagger'. The tagger can also be a function if your Msg type takes an argument, then it is 'tagging' its argument as an event to pass to your update function. So a re-usable 'component' in Elm does not need to encapsulate all of events, state and visual elements as Richard describes. But you can very easily build re-usable view elements. Do this as and when you need to re-use stuff by harvesting from your existing view code by introducing parameters. -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[elm-discuss] Re: Inter triplets communication.
On Monday, November 28, 2016 at 2:01:34 PM UTC, sergii.k...@zalando.de wrote: > > I feel it will be too messy to keep all this inter-triplet logic here. Is > there a better way? Maybe something similar to pub/sub or I'm > fundamentally wrong here? > I've pulled out a message channels pub/sub implementation, adapted from Gusztáv Szikszai's elm-ui (https://github.com/gdotdesign/elm-ui). It can be found here: https://github.com/rupertlssmith/elmq So far I have only had to do 'inter-triplet communication' for the same reason as you: handling user logins. For changing the 'auth state' of the application, I set up message channels (called login, logout, refresh and unauth). These are all fire and forget operations; they do not need a reply from the auth module. This makes them well suited to using this style. I originally started out doing this with ports but have now switched to a pure effect module. This effect module is not part of the official packages - nor have I tried to get it accepted. Still evaluating, but generally I think it is a reasonable idea. For modules that need to know what the current 'auth state' is, I implemented different views that get selected at the top-level depending on what the current users logged in state is. Like this: if authenticated && hasPermission then app model else if authenticated && not hasPermission then notPermitted model else if not authenticated && logonAttempted then notPermitted model else welcome model That is basically the top-level of my applications view. When authenticated with the right permissions, show the app. If not having the right permission, or a login attempt just failed, show the 'not permitted please retry' view, otherwise show the welcome screen. Works for the auth scenario, but feels a bit hacky to me. Certainly not a generalizable solution for building components. -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
