I like that. I hadn't thought about the option of having the login logic signal that it was done by returning a totally different type in the model position. Then the state machine can map that result appropriately.
Mark > On Aug 8, 2016, at 6:43 PM, Ian Mackenzie <[email protected]> wrote: > > I do rather like #2 - it seems to me that you could even have the result of > update be either the usual model/command pair or a UserId, i.e. replace both > return values, not just the second one. Something like: > > type State > = Active ( Model, Cmd Msg ) > | Finished UserId > > update : Msg -> Model -> State > update msg model = > ... > > which is very explicit - either we're still in the process of logging in, so > here is the updated model and some more commands to perform, or the user has > finished logged in so you should use the returned user ID to switch to some > new state. > >> On Tuesday, 9 August 2016 10:12:26 UTC+10, Mark Hamburg wrote: >> Here is the case I'm looking at: My SPA can be in one of three state — >> probably more before I'm done but three will be sufficient for this >> discussion — logging in, active, and logged out. So, here's my model: >> >> type Model >> = LoggingIn LoggingIn.Model >> | Active Active.Model >> | LoggedOut LoggedOut.Model >> >> The message handling has appropriate tag messages and the update function >> looks fairly nice by casing on (msg, model). All good so far. >> >> Now, for the question: How best to drive state transitions? >> >> For example, when we finish logging in, we should get back a UserId that we >> can hand to Active.init to get an (Active.Model, Cmd Active.Msg). How should >> this be reported? The cases I've considered include: >> >> 1. Add an extra Maybe UserId result to LoggingIn.update. >> >> 2. Replace the second result from LoggingIn.update with something that can >> be either a Cmd LoggingIn.Msg or a LoggedIn UserId. >> >> 3. Add a loggedInUser : Model -> Maybe UserId function to the LoggingIn >> module and test this after doing the update. >> >> Interesting side question: If we do succeed in logging in, is it ever >> reasonable to be returning commands (effects) from that update to the >> logging in model? The results aren't going to get routed back because that >> model state is going away. On the other hand, if we were just sending off >> some sort of external effect for which the result didn't matter, then maybe >> this could come up. >> >> If the answer to the side question says "yes, it is reasonable to send off >> commands as part of login success", then the second option needs a more >> complicated type since we can return both a command AND a user id. In that >> case, the first case probably wins. >> >> On the other hand, returning triples with what in the general case will be >> arbitrary third parameters feels like the sort of coding pattern that decays >> into returning quads and quints. >> >> The benefit of the third path is that now one could imagine testing the >> logging in module by itself with a view case for when logged in. The state >> machine just drives us from this state to the active state. >> >> The downside to the third path is that now every state implementation needs >> to include a state for while it is doing what it would ordinarily do and a >> state for when it is time to move on and that's more plumbing at those >> levels. For example, the Active module would similarly gain an isLoggedOut : >> Model -> Bool function and the model within the module would need to handle >> the logged out case even though it really has nothing to do in that case, >> >> How would more experienced Elm coders handle this? Is there a sense for best >> practice? >> >> My personal inclination is probably to go for the first option even though >> it starts to step out onto the slippery slope. I like the second approach >> because it feels more rigorous but I think that extra rigor just turns into >> extra code in practice. My first implementation today pursued the third >> course and I thought it looked nice in my top-level module until I thought >> about the fact that it would turn everything below it into a state machine >> as well. >> >> Mark > > -- > 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. -- 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.
