Skip to content

Eliminate sync_viewport_blueprint #4440

@jleibs

Description

@jleibs

The current blueprint design allows the UI to edit a mutable copy of the blueprint and then syncs all the changes back to the store at the end of each frame.

The new design uses SystemCommand::UpdateBlueprint to send changes back to the store.

To finish this migration, we need to refactor blueprint lifecycle, construction and component patterns for the remaining types:

  • Each type: ViewportBlueprint, ContainerBlueprint, SpaceViewBlueprint, DataQueryBlueprint should all follow the same design. They are generally considered to be read-only views of the blueprint on the current frame. They should always store their own BlueprintId, which is mappable to an EntityPath used to store any edits. These edits are always deferred through the CommandSender and won't be visible until the next frame. The basic pattern should look like:
    /// Create a new ephemeral blueprint entity.
    ContainerBlueprint::new() -> ContainerBlueprint;
    
    /// Send the initial state of an ephemeral blueprint entity to the store
    /// Should never be used on a non-ephemeral blueprint entity such as created via `from_store`
    ContainerBlueprint::save_initial(deferred: &CommandSender);
    
    /// Remove the entity and all of its children
    /// Note: because blueprint entities aren't stored hierarchically this will generate multiple clear events.
    ContainerBlueprint::clear(deferred: &CommandSender);
    
    /// Load an actual blueprint component from the store.
    /// Recursively loads all the referenced types.
    ContainerBlueprint::from_store(store: &StoreDb, id: ContainerId) -> ContainerBlueprint {...}
    
    /// Modify some field.
    /// Used by UI events to modify the blueprint component. Encapsulates all 
    ContainerBlueprint::edit_foo(foo: Foo, deferred: &CommandSender)
    

When this is complete, sync_viewport_blueprint should no longer be necessary.

Metadata

Metadata

Assignees

Labels

🚜 refactorChange the code, not the functionality🟦 blueprintThe data that defines our UI

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions