Published July 11, 2016 ·
6 Minute Read ·
∞ Permalink
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?
Published July 5, 2016 ·
4 Minute Read ·
∞ Permalink
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?
Published June 27, 2016 ·
7 Minute Read ·
∞ Permalink
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…
Published June 23, 2016 ·
9 Minute Read ·
∞ Permalink
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.
Published June 17, 2016 ·
4 Minute Read ·
∞ Permalink
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.