We should prepare some kind of data structure that can track and serialize the state of the regulations editor at the backend. Similar to RegulatoryNetwork, but suitable for editing.
Things to consider:
It should be serialize-able. Either through some custom from/to implementation (ideally into JSON), or using serde.
We don't necessarily need integer IDs for nodes/regulations, but we probably need some kind of ID because if we rename a node, we probably don't want to go through all regulations and change the name there as well. Additionally, it would be nice to be able to have different nodes with the same name.
My idea is the following: Have a string ID and a string name for each node. This is how it's done in SBML. Then, the name can be basically any string, but ID has a reasonably strict format (e.g. C-like identifier). Hence we can change the name without changing the ID, plus we can load SBML models without renaming/normalization of variable names.
Later on, we might consider more granular static constraints on regulations.
Currently, the layout is simply the position of the node. Later this could be also some other style, but let's not worry about this for now.
Finally, while the data structure should have a normal Rust API, we need to think about its updates in terms of reversible events that can be triggered from the UI.
We should prepare some kind of data structure that can track and serialize the state of the regulations editor at the backend. Similar to
RegulatoryNetwork
, but suitable for editing.Things to consider:
serde
.