Would sum types work with your "One Last Pattern" section? about elm-architecture-tutorial HOT 8 CLOSED

Yes, totally! I just wrote up an internal document for Prezi that shows "the most general version" of update:

update : UpdateContext -> Action -> Model -> (Model, Effect)

-- whatever other information is owned by a parent module
type alias UpdateContext =
    { userName : String
    , ...
    }

-- request effects from the parent module
type Effect = Print | LoadUserPicture | ...

One cool thing about this is that it makes it super easy to cache and batch HTTP and database requests. If 4 different pieces need the user picture, we can be abstract about requesting it, and at the top create a cache of recently loaded images so we can skip the request.

I'll be writing about this for real as soon as I can!

from elm-architecture-tutorial.

The true most general version is probably like this:

update : UpdateContext -> Action -> Model -> (Maybe Model, Effect)

Which would let you delete yourself. I guess that could be exposed through the Effect union type as well though, so maybe this is isomorphic to the most general version :)

Do these comments clarify things? I think the big message is that you can be quite flexible in the return type to cover your particular case. I don't yet know "the one best way to do it" yet.

from elm-architecture-tutorial.

Do these comments clarify things?

Sure, totally.

Which would let you delete yourself.

That only makes sense of the model is itself a Maybe at its root node, which for many things doesn't even make sense. I guess you could try to structure models to be composable, where that might make sense. But I have no idea how you could split models into sub-components using Elm. Absolutely none.

from elm-architecture-tutorial.

But I have no idea how you could split models into sub-components using Elm. Absolutely none.

That was because I hadn't read your tutorial carefully enough. But now I have, and I do get it better. Well done! Nice tutorial!

from elm-architecture-tutorial.

I'd love to see a working example of using this generalized version of update .

I'm trying to make an Effect that fetches some JSON via a port as a work around until Elm 0.15 comes out. But struggling a bit.

from elm-architecture-tutorial.

Here's my first attempt

https://gist.github.com/srobertson/3c1f2ad09d50cc054297

from elm-architecture-tutorial.

I have used this archtecture a few times now and I've realized that I often have NoOp in my actions. To distinguish them I give them different names: NoClick, NoChange, NoMove, etc...

So, I kinda switched from dealing with Action to Maybe Action as it is more general and allows me to avoid having all of these NoOp thingies.

So, as such, I think that the general case would be :

update : UpdateContext -> Maybe Action -> Model -> (Model, Effect)

And, I don't know about the deleting oneself. I think that intent should be passed in through the Effect type and the parent is the one who decides. It kinda helps make things more general because you might just have a button and it so happens that this button is shaped like an X and deletes itself but it's just a button and should only communicate that it got clicked in some sense.

from elm-architecture-tutorial.

Alright, examples 5 through 8 should give a more comprehensive answer to this question now. If you want to do custom effects that handle GraphQL and the like, you can make a graphql-effects that is based on the elm-effects package as a basic foundation.

from elm-architecture-tutorial.