Closed ondrej33 closed 9 months ago
A quick note for me: Currently, most actions that do not directly modify an ObservableState
are handled through two objects: one that performs an action, the other that listens to the result. We should probably turn this into a Promise
that is returned by the action method instead of having two objects. But this is handled completely on the frontend, the backend should work the same way it is working now.
The main issues have been (to a certain extent) resolved. The current event API will need some updates/polishing in the future, but the general logic is hopefully in place.
The most important part is the API for model-related events, provided in the src/aeon_events.ts
. In an upcoming PR, we should integrate the front-end and back-end, making use of this event API in the TypeScript code. For more information about the Rust implementation of these events, see the struct ModelState
, mainly its implementation of the SessionState
trait in src-tauri/src/sketchbook/_model_state/_impl_session_state.rs
.
This seems to be working now. There might be a few things that we need to solve down the line, but we'll merge it and work on new stuff in separate PRs.
This PR implements the backend for tracking and validating the state of the model edited in the regulations editor. It is synchronized with the frontend using events.
The events supported by the main
ModelState
struct are listed in thesrc/aeon_events.ts
file.Before reviewing and merging this, finishing at least some of the following things would be nice. However, (except for the first one?), they can be addressed via some subsequent PR.
ModelState
events into "two groups" - (A) those for adding new objects (regulations, variables) and (B) those for modifying/removing the existing objects. This would enable us to fix some issues with paths and payloads. Events of group A would have a more general path, such as ['model', 'regulation', 'add'], and carry a JSON payload fully encoding some prepared structure (such asRegulationData
). Events of group B would have more specific paths encoding the specific object, such as ['model', 'regulation', 'regulator_id', 'target_id', 'remove']. The payload of these events could then be just a single value or even be empty sometimes (now, all the IDs are also part of the payload, making it "bloated").ModelState
and add tests for the some remaining cases.src/aeon_events.ts
reflecting the previous points.refresh
part of theSessionState
API forModelState
. There is a placeholder currently, and all the "getter" events should be added.