Understanding the purpose of "init" and improving app design

[rupert]

@nickwalt

I understood Life of a File as a recommendation to only move to Modules when data naturally evolved into groups of types that could be moved out of Main.elm together. However, it seems that, especially if we use something like domain-driven type design, and given the considerations that Evan draws our attention to, it might also be good to move to using Modules and more sophisticated patterns sooner rather than later (or as a matter of course in contemporary Elm practices).

There was this post a while back about putting an entire application in one big file:

Large file for new application

I’ve been using Elm on and off for a few years and I’m about the start a small/medium sized app (probably end up around 10k-20k loc). I’m toying with the idea of keeping the entire application in one giant file for several reasons: Abstraction to separate modules always produces a ton of boilerplate and indirection (in my experience) Everything can be scoped in a file. I’m curious how it’ll play out (miserable failure or epiphany!) I’m curious if anyone else has experience with really big fi…

Inspired by this I worked on an application where I put >5K lines in a single file. The intention was not to keep it that way forever, but to experiment with the idea of building up a lot of code before deciding how to split it up into modules, so that the splitting up was informed by the application design I arrived at naturally, rather than being imposed onto it according to some pattern I decided on before hand.

Managing the 5K file got tricky and eventually began to slow me down. I could really have done with better editor support (maybe that does exist I just didn’t have time to investigate what is available, was using vscode).

Overally, I would say that this has been a really useful exercise for me. I now have this application split up into 20+ modules. I have not needed to create any nested TEA components. I have not used any ‘out messages’ and now strongly consider this an anti-pattern in Elm. I have used extensible records to take slices of a big model, and build modules around those types, which is a very flexible way to manage things. It is also very easy to change the slicing at a later time, since the model is flat and you don’t have to unwrap/rewrap everything to arrive at a new model design.

There are domain models within this, which usually get their own module, or a cluster of them together in a single module. Domains types are often opaque with ‘smart constructors’.

So I would say the opposite, move to modules once the justification for doing so becomes clear and is guided by the actual application design. Use the simplest patterns you can - Elm generally makes more sophisticated patterns more expensive to use. Its easy to be too clever and end up with code that is just harder to write and manage than it should be. KISS - keep it simple stupid!