TL;TR: using **type parameters** we can simplify the main update function, moving the logic to the submodule.

The code for this post is available on a github repository.

Achieving modularity in Elm is at the same time **easy and hard**.

It is easy because **it’s almost impossible to break things even with big refactorings** but on the other hand **the constraints of pure functional programming can be challenging** when deciding how to split the application into submodules.

### The model

Imagine you have a **Model** describing a basic shopping cart:

1 2 3 4 5 |
type alias Model = { name : String , details : Details.Model , invoice : Invoice.Model } |

Where the models in modules **Details** and **Invoice** are defined as:

1 2 3 4 5 6 7 8 9 10 |
-- Details.elm type alias Model = { quantity : Int } -- Invoice.elm type alias Model = { price : Float } |

This is an oversimplified example, just to show a basic modules subdivision, where we have only two messages: `Increment`

and `Decrement`

.

## The isolated-model approach

### The update functions

In the **Details** module, the `update`

function will take care of updating the `quantity`

field summing the input number, just preventing it from being assigned a negative amount:

1 2 3 4 5 6 |
update : Int -> Model -> Model update number model = if model.quantity == 0 && number < 0 then model else { model | quantity = model.quantity + number } |

In the **Invoice** module, the `update`

function will take care of updating the total price based on the quantity value passed as an input:

1 2 3 |
update : Int -> Model -> Model update quantity model = { model | price = (toFloat quantity) * 1.5 } |

Finally, the main `update`

function is in charge of running the submodules’ functions and put together the data for the new model. This is the code handling the `Increment`

message:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
update msg model = case msg of Increment -> let newDetails = Details.update 1 model.details newInvoice = Details.mapQuantity Invoice.update model.invoice newDetails in { model | details = newDetails , invoice = newInvoice } Decrement -> -- Same with -1 |

Let’s break it down: first, I calculate the new model for **Details** since its result will be used to calculate the price and I store it in `newDetails`

.

Subsequently, I calculate the new model for **Invoice** using the helper function `Details.mapQuantity`

since I don’t want the inner structure of **Details** model to be exposed. The helper function itself is simply:

1 2 3 4 5 |
-- Details.elm mapQuantity : (Int -> a -> b) -> a -> Model -> b mapQuantity f input model = f model.quantity input |

Let alone the fact that the code can be written in a more concise (and somehow difficult to read) way, this pattern (which I called the **Isolated Model**) makes the main `update`

function verbose and prone to errors, given that a simple application could be composed of tens of modules.

The most common mistake that I do is to assign the wrong model to the final model output:

1 2 3 4 5 6 7 8 9 10 11 12 13 |
let newDetails = Details.update 1 model.details newInvoice = Details.mapQuantity Invoice.update model.invoice newDetails -- ...more logic here... newOtherModule = -- ERROR: the model I'm passing here is the one updated -- by Details. The compiler won't complain, but the result will be -- wrong. OtherModule.doSomethingBasedOnInvoice newDetails in -- ... |

## The SuperModel approach

In Elm, I can tell the compiler that I want a record with some specific properties defined regardless of what else it contains:

1 2 3 4 5 6 |
type alias Model = { price : Float } type alias SuperModel a = { a | invoice : Model } |

It means that **SuperModel** is a union of a record of type *a* and a record with a field `invoice`

of type **Model**.

We can now define the updates functions in terms of **SuperModel a**:

1 2 3 4 5 6 7 8 9 10 11 |
-- Invoice.elm update : Int -> SuperModel a -> SuperModel a update quantity superModel = let model = superModel.invoice newModel = { model | price = (toFloat quantity) * 1.5 } in { superModel | invoice = newModel } |

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
-- Details.elm update : Int -> SuperModel a -> SuperModel a update number superModel = let model = superModel.details in if model.quantity == 0 && number < 0 then superModel else let newModel = { model | quantity = model.quantity + number } in { superModel | details = newModel } |

As you can see, the functions are a bit more verbose than before: we just moved the complexity into the single modules, thus allowing the **Main** `update`

function to become simpler:

1 2 3 4 5 6 7 8 9 10 |
update : Msg -> Model -> Model update msg model = case msg of Increment -> Details.update 1 model |> Details.mapQuantity Invoice.update Decrement -> Details.update -1 model |> Details.mapQuantity Invoice.update |

The main advantage in this scenario is that we can pipe the update functions (and even the **map** one) since they all accept the same input.

I’ve found this pattern pretty clean and usable because now my **Main** is easier to read and all the functions are guaranteed to receive as input the latest updated **Model**.

**There is still room for logical errors** though: for instance, I could have two interdependent updates be run in the wrong order. But with the piping syntax, I find them easier to spot and fix.

## 2 Comments

Join the discussion and tell us your opinion.

You can (potentially) clean this up further using pattern-matching: https://ellie-app.com/3Mx5qb9tzx7a1/0

wow! I didn’t think about it, thanks. It could become a bit complex for non-trivial updates, but still, I like its conciseness.