-
-
Notifications
You must be signed in to change notification settings - Fork 3.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add EntityCommands::with_child
and EntityMut::with_child
#6716
Conversation
@@ -252,6 +252,9 @@ impl<'w, 's, 'a> ChildBuilder<'w, 's, 'a> { | |||
|
|||
/// Trait defining how to build children | |||
pub trait BuildChildren { | |||
/// Spawns a new entity for the provided `bundle`, and adds it as a child entity to the parent | |||
fn with_child(&mut self, bundle: impl Bundle) -> &mut Self; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd be inclined to make this return ()
, as this could reasonably return either Self
or a version of Self
for the new entity (especially as there's no way in this API to get the new child's id directly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think users would get that it's returning the child_builder cause that's a common pattern used in Bevy.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Returning self is actually quite useful: you can spawn multiple children under the same parent by chaining it. I should improve the docs to explain that though.
I didn't change the examples to use that pattern though, as it would be pointlessly controversial.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I was a bit confused by that too. I think it makes sense as it is and overall is more useful this way, but I do think there's some potential for confusion here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, I also wanted to maintain consistency with with_children
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems to be common enough to warrant this addition.
I wonder if it would be possible to add a with_children
that takes an iterable of children which are then all added?
I assume that wouldn't be possible because the children would have different types?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like it, a bit less nesting and less boilerplate in general is always appreciated.
@TimJentzsch precisely, which is why the existing technique uses a closure. |
Co-authored-by: ira <[email protected]>
Thanks @devil-ira; those are much nicer little code snippets than my first attempt. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These examples look so much nicer!
bors r+ |
# Objective - Adding a single child is very cumbersome, and requires the use of a complex closure. - Fixes #6712. ## Solution Add a `with_child(b: impl Bundle)` API. ## Changelog Added `EntityCommands::with_child(b: impl Bundle)` and an equivelent method on `EntityMut` (for direct world access). ## Migration Guide When spawning a single child with no children of its own, consider using `commands.entity(parent).with_child(child_bundle)` to make your code clearer.
Build failed (retrying...): |
This clashed pretty hard: I think it's going to be more reliable to rebase more manually: I don't want to risk messing up the changes from #6727. |
# Objective - Adding a single child is very cumbersome, and requires the use of a complex closure. - Fixes #6712. ## Solution Add a `with_child(b: impl Bundle)` API. ## Changelog Added `EntityCommands::with_child(b: impl Bundle)` and an equivelent method on `EntityMut` (for direct world access). ## Migration Guide When spawning a single child with no children of its own, consider using `commands.entity(parent).with_child(child_bundle)` to make your code clearer.
Build failed (retrying...): |
# Objective - Adding a single child is very cumbersome, and requires the use of a complex closure. - Fixes #6712. ## Solution Add a `with_child(b: impl Bundle)` API. ## Changelog Added `EntityCommands::with_child(b: impl Bundle)` and an equivelent method on `EntityMut` (for direct world access). ## Migration Guide When spawning a single child with no children of its own, consider using `commands.entity(parent).with_child(child_bundle)` to make your code clearer.
Build failed: |
While this is an improvement, I feel like it's a bandaid on a deep wound... |
This needs to be rebased, and I'm not thrilled with the fact that this isn't chainable. Moving to draft. |
I don't think this should be merged:
|
Firmly agree on the confusing diversity. Closing this out for now; I'd rather put the effort into other work to fix this mess for real in one form or another. |
Objective
with_child
method toBuildChildren
#6712.Solution
Add a
with_child(b: impl Bundle)
API.Changelog
Added
EntityCommands::with_child(b: impl Bundle)
and an equivelent method onEntityMut
(for direct world access).Migration Guide
When spawning a single child with no children of its own, consider using
commands.entity(parent).with_child(child_bundle)
to make your code clearer.