[elm-discuss] Re: Discovery: Model /= Database

This topic is a bit all over the place, but just wanted to chime in with a different approach that I've found works pretty well for updating database-backed state, especially in contexts where you aren't syncing with the backend via websockets or similar. That is to follow the principle: no

[elm-discuss] Re: Discovery: Model /= Database

The pattern we use is to have our Page.update functions return (model, cmd, storeCmd) the main update then applies the storeCmd to the Store. (the actual code supports a few other things but that's the basic gist of it). Hit me up on slack if you want to chat about it. On Sunday, 30 April

[elm-discuss] Re: Discovery: Model /= Database

I think I've just had an aha moment with this post. I am in the process of refactoring my monolith MUV into separate modules with their own MUV for each "page" of my SPA. Up to this point, I have had a separate Store module with its own Model and Msg types and an update function (no view,

[elm-discuss] Re: Discovery: Model /= Database

Hi Kasey, I just wanted to mention that the wikipedia article Model-view-viewmodel might be helpful reading. In some architectural patterns this is called the viewmodel rather than the model. (A couple of GUI oriented

[elm-discuss] Re: Discovery: Model /= Database

Interesting approach to just cache things in local storage and use the Model as a view "state" only. I keep a nice store in my Model, but I think a key difference is that I'm using websockets to update information automatically. Each route (page) has a list of channels that it cares about,