Nine Guidelines for Modular Elm Development

Great article! (in fact I’m finding you Elm series really insightful).

I’m following a very similar approach with a few differences. Instead of View, Update and Model I name my files View (same as yours), State (update function, initState and helpers), Types (models, msg) and Rest (decoders and command helpers). The “Types.elm” name makes more sense to me as it holds not only the model, but also the messages and other custom types you need. That is the single file you would need to import everywhere to make type annotations. I’ve found I solved almost every circular dependency issue I had using this approach.

Another difference is that I organize the files “by domain”, so if my app has “movies”, “actors” and “awards” I would have a folder for movies, one for actors and one for awards, each of which containing a Types, State, View and Rest files. I find that generally when working on a specific domain one need to edit its files at the same time so having them together seems more convenient.

Looking forward for more posts!