Its possible to do this, but I don’t think it will be at all helpful. In fact, that version number is capturing model state, since it is +1 from the previous model version and not a delta:
-- Somewhere in the view
SomeMsg (model.version + 1) -- captures model state!!
-- Should be a delta
SomeMsg 1 -- Here 1 just means bump the version by 1, its a delta, also pointless but just to illustrate.
An update
function can receive Msg
s from multiple sources - the view
, the subscription
or some Cmd
it ran earlier that is going to produce a response, such as an HTTP request. It is actually perfectly ok for there to be many events in the queue awaiting processing by the update
function, and those events can perfectly legally have been built upon earlier versions of the Model
, without harm - so long as they are deltas and do not capture any absolute model state.
If you force a strict version numbering sequencing, it means that each event can only legally have been generated from the current-minus-one Model
version.
Suppose you fired off an HTTP request some time ago, then the user clicked some buttons to filter or organize data in a table, and then the HTTP response comes back and you want to add more data into the table. Maybe that HTTP response was sent on the current-minus-ten version of the Model
, but it is still valid to the current application state, so it should be all ok.
Better is to define the application as a state machine:
type Model =
| WorkingWithTheDataTable { records : List Record, tableFilter : Filter, whatever ... }
| DoingSomethingElse
So there can simultaneously be events going on around how the table is viewed, and how its data is populated, but the state remains the same as these events are processed.
If you switched to the DoingSomethingElse
state before the HTTP request for table data comes back - then that event can be ignored based on the application state.
Use a state machine to turn the real world event stream into a sufficiently ordered stream of allowed events. There is no need to totally order events in lock step, as that dissallows event orderings that will happen in the real world and that should be allowed by the application.
If you need to break down the WorkingWithTheDataTable
state into a more fine grained state machine for working with table views - you can do that too, and nest its state machine inside the overall one for the application.
My recommendation is to always draw a pen-and-paper sketch of your application state machine, and iterate that sketch a few times till you get it right.