Elm

Duplicating Scientists in Elm: Stop Sharing State


When you’re building an app with Elm, you’ll find a common problem: where do you put shared state in models? Let’s take selecting an item for viewing as an example. You’ll start out having a model field with a selected item and one with a collection. But that’s duplication! How do you keep the model state in sync when one side has to change?

Read on

Duplicate, Message, or Update? Contexts in Elm Components


Imagine: you’re implementing your Elm app. It’s getting bigger all the time, and you’re happy that it’s growing. Hooray! But now you need to make HTTP requests… from a child component. What to do? You don’t want to duplicate the HTTP config as a field on the user everywhere, right? But likewise, you don’t want to forward actions to the parent just to make HTTP requests, right? What’s the way to solve this while sticking with the best architecture for your app?

Read on

Candy and Allowances, Part II: Child-Child Communication in Elm



UPDATE 2017-01-16: before you read this, read the reuse section of the Elm guide. It will set you up in a better way! The text below is preserved for reference purposes.


In our previous article we talked about how parents and children can communicate with one another in Elm. But how about when you need two child components to know about each others state? Hmm…

Read on

Candy and Allowances: Parent-Child Communication in Elm



UPDATE 2017-01-16: before you read this, read the reuse section of the Elm guide. It will set you up in a better way! The text below is preserved for reference purposes.


Nobody wants to feel like their application holds together by duct tape and baling wire. Coupling components is icky, but… sometimes you’ve got a parent and child components that just have to talk to each other. It can feel like you’re missing something simple when these situations come up. Do you have to give up on clean separation of concerns just to get it working? There’s hope, though: this problem is not as difficult as it seems on the surface.

Read on

How does Json.Decode's andThen work?


It’s easy to get stuck decoding JSON. First of all you have to understand how to write a Decoder, and then… well, then you get to andThen. The docs have a terse explanation (“Helpful when one field will determine the shape of a bunch of other fields.“) and give the following example:

type Shape
    = Rectangle Float Float
    | Circle Float

shape : Decoder Shape
shape =
  ("tag" := string) `andThen` shapeInfo

shapeInfo : String -> Decoder Shape
shapeInfo tag =
  case tag of
    "rectangle" ->
        object2 Rectangle
          ("width" := float)
          ("height" := float)

    "circle" ->
        object1 Circle
          ("radius" := float)

    _ ->
        fail (tag ++ " is not a recognized tag for shapes")

This is frustrating the first time you look at it. What’s important and unimportant in the example? What shape of JSON do I even pass in here? But there’s hope! Once you know where to look, it’s pretty simple. Let’s break it down.

Read on