On Monday, November 28, 2016 at 2:01:34 PM UTC, [email protected] 
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 [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to