There are several pieces of refactoring that will benefit the ongoing blueprint migration:

• Rename or encapsulate DataResultTree -> QueryResult and move DataQuery evaluation earlier in the frame:
  • Will be done in: Move DataQueryResults into the ViewerContext #4310
  • The location is roughly app_state.rs :: show() or equivalent. Right before we create ViewerContext.
  • All QueryResults will be added to the ViewerContext.
  • Invocations of execute_query and resolve from the DataQuery trait are instead replaced by something that looks up the QueryResult in the ViewerContext.
  • Future: QueryResult can be merged with the QueryCache logic.
• Replace SpaceViewContents with DataQuery
  • Will be done in: Fully migrate to DataQueryBlueprint #4311
  • Everywhere that we use SpaceViewContents needs to use an appropriate QueryResult instead
• Moved to: Eliminate sync_viewport_blueprint #4440
  Refactor blueprint lifecycle, construction and component patterns.
  • Each type: ViewportBlueprint, ContainerBlueprint, SpaceViewBlueprint, DataQueryBlueprint should 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 be completely gone.
• Moved to: Deprecate "groups" as a concept from the DataResultTree. #4441
  • Deprecate "groups" as a concept from the DataResultTree.
    
  • Now we have "groups" which map to override-recursive and "entities' which map to override-individual
  • After we will have entities with two override paths: "override" and "override_recursive". The UI can then choose which path to use depending on some context of how the override is being set (i.e. a flag for "apply to children")