Recommended Way To Replace UI Elements

[Magnitus-]

I have a sub-section of a ui menu that I want to refresh when a component in my game model changes.

So in a system that reacts to the component change, I want to delete all the children (and their children) of an ui entity and from there re-generate new children.

At first I tried this to delete all the children:

#[derive(SystemParam)]
struct UpdateActionMenuQueries<'w, 's> {
    action_menu_query: Query<
        'w, 's, 
        (Entity,),
        (With<ActionMenu>,)
    >,
    ...
}

pub fn update_action_menu(
    mut commands: Commands,
    ...
    queries: UpdateActionMenuQueries
) {
    ...
    let (entity,) = queries.action_menu_query.get_single().unwrap();
    let mut entity_commands = commands.entity(entity);
    entity_commands.despawn_descendants();
    ...
    //Repopulate children under entity_commands
}

And that didn't work (the action menu was blank). I guessed it was because the "despawn_descendants" command ran asynchronously and actually deleted the new children I created right after calling it.

So then, I tried this to instead target more exactly what I wanted to delete:

#[derive(SystemParam)]
struct UpdateActionMenuQueries<'w, 's> {
    action_menu_query: Query<
        'w, 's, 
        (Entity, &'static Children),
        (With<ActionMenu>,)
    >,
    ...
}

pub fn update_action_menu(
    mut commands: Commands,
    ...
    queries: UpdateActionMenuQueries
) {
    ...
    let (entity, children) = queries.action_menu_query.get_single().unwrap();
    for &child in children.iter() {
        commands.entity(entity).remove_children(&[child]);
        if let Some(mut child_commands) = commands.get_entity(child) {
            child_commands.despawn_recursive();
        }
    }
    let mut entity_commands = commands.entity(entity);
    ...
    //Repopulate children under entity_commands
}

And that worked a lot better. But now, I'm getting a bunch of warnings like this:

2024-09-30T08:40:20.999217Z  WARN bevy_ecs::world: error[B0003]: Could not despawn entity Entity { index: 172, generation: 1 } because it doesn't exist in this World. See: https://bevyengine.org/learn/errors/#b0003

I'll guess that the existence guard I put on before deletion doesn't help, because the deletion is also asynchronous (so the entity exists at the moment of the check, but no longer exists at the moment of the asynchronous deletion).

I took the hint that I should despawn the entities after removing them as children here, but not sure if that bit of info is obsolete or not: https://bevy-cheatbook.github.io/fundamentals/hierarchy.html#despawning-child-entities

Given that the ui parent-children hiearchy is a tree and don't have any loops, I'm guessing that the "despawn_recursive" is not the problem there.

Any insight would be most welcome.

[Magnitus-]

Thinking about it, it is "only" a warning I guess, though in a worse case scenario, it might leak memory (I'm guessing those recursive deletion are not running as some elements are deleted some other way it seems, but it is unclear to me whether the entire hierarchy is deleted when that happens).

I'll make a note to refactor this later on by just tearing down and re-creating the entire menu. At least deleting an element recursively at the root of the hierarchy has worked well in the past.

[ShreyK]

I have found using Events as the best way to update anything UI related.
For eg:
#[derive(Event)]
pub struct AddCargoItemEvent { ... }
#[derive(Event)]
DespawnCargoItemEvent { ... }

Ideally you would have minimal attributes in each of these structs (preferably Entity's) that you can use in conjunction with Queries to do any spawning/updating/despawning

[ShreyK]

You will end up having a lot of events

But so far it has kept my code relatively clean while also keeping the game ui responsive.

[Magnitus-]

I have found using Events as the best way to update anything UI related. For eg: #[derive(Event)] pub struct AddCargoItemEvent { ... } #[derive(Event)] DespawnCargoItemEvent { ... }

Ideally you would have minimal attributes in each of these structs (preferably Entity's) that you can use in conjunction with Queries to do any spawning/updating/despawning

It depends on the need, but I've done that for interactive/reactive ui elements, though I use change detection on components instead of events to react to and propagate changes.

I have regular buttons, radios, radio menus (menus that show/hide depending on which radio element is selected), textboxes, tooltips (text display that is hidden and populated and shown when button with the right components is clicked on and then disappears when anything is clicked on), paginators (page-tagged elements that are shown/hidden when buttons with the right components for up/down are clicked and the buttons will also show/hide depending on which page is displayed), popups and discrete pools (used when you have a shared pool of something discrete to assign to various elements, often used in rpgs for character creation among other things). Right now, I'm really focused on progressing with my project, but once things are a bit less hectic, I'll probably do some proper clean up and publish that part.

As long as I focused on properties (ex: changing the image, showing/hiding stuff, etc) or recursive deleting ui elements at the root during entire menu cleanups, everything was right as rain.

I started hitting my head against the wall once I felt the need to prune out specific subsets of the ui hiearchy that are not at the root and I was wondering what the proper way to do that is (ie, untangle the child/parent relationship and delete the child and all its children recursively). I guess I could add an additional component to the top children of the entity whose children I want to clean up and select them that way instead of iterating over the children, but then I'll encounter a similar problem as when I just iterate over its children to delete them no?

Anyways, right now, I managed to downgrade it to a bunch of warnings and I have a gameplan for a workaround to do it another way that doesn't do that, but some people who really want to do that might want to know how (or might want to know that you really should not do that as the case may be).