Redesign model inputs into "store" pattern

[pinkwah]

The models page has problems that make it difficult to handle the input flow. In particular, I would like to have the following features be available:

• Setting the selected model and model input to something specific (eg. when the user sends a link with simulationId)
• Flagging when the input has changed (eg. the user clicks on a simulationId link and types a different number for H2O, it should be evident that this happened)
• Reverting changed values back to their defaults / past simulation inputs
• Deleting concentrations that were previously added

We can maybe have a zustand store or something with the following API (TODO: Still thinking about this):

type StoreFields {
    selectedModel: ModelConfig
}

type StoreActions {
  /** Set the input to specific values, such as when sending someone a link with a past result */
  setInput(modelId: string, inputs: ModelInputs);

  setConcentration(modelId: string, name: string, amount: number);

  setParameter(modelId: string, name: string, value: string | number | boolean);
}

We may also want to think about how we can make this work with a sequence of simulations. Maybe when the user clicks on a model, it creates some new ModelInput instance?

As only the Models.tsx page needs this, I think we can bring all the details into that file (or related files), and assume that no other page will ever use this store code. Ie, the flow of the store is allowed to be specific to the Models page.

[lars-petter-hauge]

The current structure of creating one modelinput instance for each model and change visibility upon selection was neat, but not very extendable.

I think we should redesign a bit, and at the same time consider that it should work for multiple selected models.

I think the way inputs and outputs are stored in the database makes sense. The one to one mapping there should remain.

Perhaps we need another entity on the database? A simulationgroup? which is a uuid representing a group of simulations (name is up for discussion).

Instead of making one modelinput per model, we then have a component that will contain parameters of all (selected?) models.

Furthermore it will be slightly more complex, as we need to handle that if a model becomes invalid with given input (say a substance is added), we need to show it somehow (grey out the model?). Or we do it the other way around, selecting a model gives the valid inputs simply as the intersection of valid components (that is, only show components that are valid for all selected models)

Regarding Zustand. It kinda sounds like splitting stored state into database and react library. I think it makes sense to keep it only in one of them.

But let's discuss it more, I might be getting the wrong picture of it :)

[lars-petter-hauge]

We may also want to think about how we can make this work with a sequence of simulations. Maybe when the user clicks on a model, it creates some new ModelInput instance?

This to facilitate having one model run with the output from another model as input? (as in reactional first, the solubility?)