This is a zero-change in terms of the application functionality. The main motivation comes from #5 (closed) to allow us to:
- Easily hold on to multiple model states for use in comparisons
- Modify the model state conveniently, and have it update the application automatically
- Implement a MVC-like abstraction to allow us to easily build applications without needing them to be tailor made inside a notebook
- Move the existing application out of the notebook and into testable & reusable components
This rather large change adds a layer between the underlying (immutable) model and the application. In doing so we can avoid the use of a global state (useful for the purposes of configuring multiple models in the same application later on) and it also unlocks the ability to implement an MVC-like separation of concerns - again, the intention is that when it comes to comparisons, we will just be able to re-use our application views.
I was hoping that
cara.state could have been avoided in lieu of using traitlets, but unfortunately I found a number of limitations which were prohibitive for its use here. Foremost of which was the lack of dataclass support, and the difficulty in needing either to use instances of the model (immutable) or duplicate the model in a mutable form and use the
traitlets.Instance type. Instead I opted for doing it myself - the
cara.state module would make a very good standalone project in the future.