title: In scala or scalajs Diode, do any of the existing types line up with the use case of "updating a model that doesn't yet exist"?
body: <p>Here's a common situation: you have a form and you're interested in the submissions of that form. You may add a wrinkle to the situation by adding a server-side validator, or even a client-side validator, but the validators are only provided as a means of ensuring the input you submit is valid at that instance; any state collected between 0 and submission is thrown away and incidental.</p>
  
  <p>Here's a less-common situation: your form has a password/confirm field that you need to wire to work in the obvious manner and wire to display an indication of password strength (and validity). In the past I've seen a lot of "write a jQuery callback for the event handler on change, and call it a day." This is just a more extreme case of needing the state in between to get to a destination, not as an end in itself.</p>
  
  <p>Now a very uncommon situation: you need to track the input of this form because it is a form used by the US government to communicate with our guys in nuclear bunkers in Wyoming. It is certainly important that form input is valid on submission, but we need to additionally know as much as we can about the way it got there. Let's say it is a login form for instance. If we track the <strong>sequence of events</strong> from 0 to submission and compare it to the past we can detect anomalies in user behavior, for instance. We can determine whether we might be having login servers problems before we hear about them. So this is not always throwaway info.</p>
  
  <p>I want to map the event <code>onChange</code> to some Diode concept, but I'm having trouble figuring out what I ought to do. Here are the options:</p>
  
  <ol>
  <li>I could define a new <code>case class</code> for each field-type and for each object-type permuted, and stick all of them in the root model (seems like a stupid way to do it)</li>
  <li>I could define a genericized data structure representing an "un-submitted change in input value" that would also indicate the model and field changing. Seems optimal but maybe unnecessary and a lot of work and hard to do well.</li>
  <li>I could use an existing data structure, like one of the <code>Pot</code>s, to stand in place for my <code>Scratch</code> data structure. Probably the best idea but not sure which to use.</li>
  </ol>
  
  <p>That's where I am at... any thoughtful advice is appreciated.</p>