Scaling Large Elm ApplicationsElm ·
In that article I developed an application which works fine, but not very convenient to extend. That is why my goal is to take advantage of a tree structure and optimally break the application down to multiple files with a narrow scope, in order to keep fewer things in mind on changing a particular part of the application.
The goal is to take advantage of a tree structure of an application since my brain processes linear structures with O(n) complexity.
By the way this guide would perfectly solve this kind of a problem for the applications with models of product type and it is actually cool how the app starts kind of consisting of smaller subwidgets, which are closed under a collection of operations, i.e. a submodel has the same type after performing an operation from the collection.
The model of my application is particularly of sum types, which comprises different states:
GameOver – the concepts which potentially can be extracted into smaller subwidgets. The problem is that the application should be able to transit from one state to another, i.e. these subwidgets no longer have the closure under all the commands that trigger the update, since one of the commands should update a submodel to a different state.
The problem is to scale an app with transitions from one state to another, which is quite natural for the games since games often have different states of the whole application with an independent state.
Let’s start from creating three separate files for every state and moving the code there:
The model structure changes from
Currently, the messages structure is
Let us notice that:
StartGamemessage is triggered during
Startstate and transmits the model into
RestartGamemessage is triggered during
GameOverstate and transmits the model into
Tickmessages are triggered during
Playingstate and do not change the type of state, but
The idea is to create a
Transitionmessage for every state and process it on a higher level in order to transit the application to another state.
As a result, we receive quite general
update function, which either calls
update functions of a subwidget depending on the message received or transmits the model into another type of state
The app renders view according to the current state and wraps the outgoing messages from subviews using
Subscriptions are handled similarly (the whole app can be viewed on GitHub )
Since we deal with mere functions and groups of functions (modules), we possess enough flexibility to say that the provided example is not the only way to structure your application. For instance, we could pass
PlayingMsg function into
update functions of
GameOver modules instead of processing
Transition messages. And it is great, that we can choose an approach which fits best for solving a particular problem ✊