Model View Controller isn't
The absolute most important thing to understand about models as they were originally intended, is that they are not descriptions of a data model per se.<p>This is not to say that data modeling is not important, or that your model won’t have a similar shape as your data model; it will. But that is not the original point.<p>In MVC as it was originally understood, a model is a list of subscribers. You can add yourself to that list, you can remove yourself from that list, and whenever a “value” changes, if you are on that list, you get a notification that the value has changed. You have a couple of different designs of these, depending on whether you want to send a current-state message as a notification on subscription, or just give everybody read access to the current state. The latter commits you to initializing your models in ways that indicate the absence or staleness of data (someone loads your app, you need to send out a network request to get a new thing) but also allows you to use variable scope to augment how much multiplexing and state tracking you need.<p>Models vary from data models in having view-relevant data. So for example you switch from the type<p><pre><code>    const urlList = new Model&lt;UrlRow[]&gt;([])
</code></pre>
to the type<p><pre><code>    type Fetching&lt;x&gt; = { state: &quot;init&quot; }
      | { state: &quot;loaded&quot;, data: x },
      | { state: &quot;fetching&quot;, staleData: x },
      | { state: &quot;fetch error&quot;, staleData: null | x }
    const urlList = new Model&lt;Fetching&lt;UrlRow[]&gt;&gt;({
      state: &quot;init&quot;
    })
</code></pre>
Notice that these Fetching indicator statuses are a part of the data model for the UI, not the underlying data model that exists at the database level.<p>If this begins to feel a lot like React and Redux, that is because there is a shared lineage there. React originally made its splash as “the V in MVC” but its setState&#x2F;state system, while it doesn&#x27;t contain a subscriber list, effectively does something equivalent by insisting on destroying anything that has the old values and then superficially identifying things which appeared to remain the same from moment to moment, with the basic model then being a “subscription tree.”<p>Redux of course takes this from being a tree to being something more generic by making the store global... I think that models should not be app-global the way that Redux likes (it does not want to solve the problem of multiplexing models, which is understandable but it turns out to be a much simpler problem than you&#x27;d think) and that the pattern of reducers is more verbose than one generally needs, but I love the time travel browser features that Redux gives me. Somehow Redux has encouraged abominations like redux-thunk which complect separate concerns into the same dispatch function unnecessarily. But the fundamental workings involve that same basic structure: a subscriber list.