| [I]t always feels like you have to keep the whole message-graph in mind It should be quite the contrary. When you design a piece of the app, the piece should have its state, messages and view code, so it should be perfectly possible to ignore any context, focusing just on the single piece. Just like when writing pure functions, for example. You cannot just run it and see how far you come, you're code just won't compile. This is a known initial hurdle with expressive static type systems I think. It gets better quickly and then you won’t be able to go back, feeling existential fear without the compiler watching your back. So your parent message contains a child message, containing some data that needs to get passed to the next view. This is getting too particular for me to explain/help/argue directly. In our app, for example, the main app model is either onboarding, home screen or signed out. Then it makes big sense for the main model to accept messages regarding onboarding, home screen or signed-out state. And when it receives a message related to one of its child states, it just delegates it. This makes sense conceptually and is quite natural to follow when reading the code. I am not an experienced Elm programmer, so maybe I am getting this wrong, but what we have has worked for us well, so far. |