ITADN

Evolution Tree

#116Pull Requestdzervas 创建于 2024-06-26
D
dzervascommented
first of all due to some technicalities we can no longer get_workbench - we shouldn't anyway (LoroDoc doesn't implement Clone so I can't just return a clone of the workbench itself) it forced a long awaited fix: JS no longer duplicates the whole WASM memory it should just hold the oplog (history) and evtree (LoroDoc) as well as a project and workbench index. that's it so JS instead of calling Project::get_workbench now calls get_workbench_oplog and get_workbench_evtree where both require a project_index and workbench_index. both regular incremented numbers, nothing fancy I also introduced set_workbench_evtree since we want a way for JS to update the evtree so what changed? - as explained above JS no longer acts on top of the `lib.rs` Project struct - it can be removed completely - but calls static global functions - for that to be able to happen, JS has to keep track of the current project and workbench index (regular 0-based indexes) - each workbench now holds an instance of the `EvTree` struct. A thin wrapper around `LoroDoc` - the `LoroDoc` holds a list of step hashes. that's it. (this choice was made for us since Loro can't hold arbitrary types) - step hashes are now unique (they take into account the author (hardcoded for now) and timestamp in addition to the message) so that we don't fall into collisions - the hashes that `LoroDoc` holds is always a sub-group of the actual history. the lorodoc can fork or whatever but the history is always linear - in order to compensate for the evtree vs actual workbench state getting out of sync (e.g. checking out before a sketch line gets created won't remove the line from the isotope sketch) a new method is introduced in the `project::Project` struct: `rebuild_workbench`. It accepts a workbench index and it: - nukes the workbench of all the internally held geometry BUT keeps the history and evtree intact - iterates through all the pointed evtree hashes (remember that loro abstracts away the complexity of the actual tree and gives us back the actual used history - from the currently checked out node to the root) - iterate through the workbench history to find the actual steps that the evtree hashes refer to - iterate through the found steps and call their handler (omitting the logic that appends them to the history and evtree) - added methods to get the evtree and oplog - added method to set the evtree but there are quite a bit to get done in the UI: - call the new global functions instead of `wasmProject.*` - no longer hold a `$workbench` state but hold `$oplog`, `$evtree`, `$project_index`, `$workbench_index` and maybe `$project` (for the name?) instead - some book-keeping is probably required for `oplog` and `evtree` (on `send_message` update them both) - introduce any required loro-releated functionality for the `evtree`
合并状态:未合并 1 条评论