bevyengine / bevyengine/bevy

Relationship::on_replace docs are confusing

Open
#20,188 4 comments 0 reactions 0 assignees View on GitHub
A-ECS C-Docs D-Modest S-Ready-For-Implementation
Dominant language
Rust
Stars
48.2k
Forks
4.8k
Avg merge
3d 16h
Merged PRs (30d)
171

Description

I'm confused by the docs for on_replace.

https://docs.rs/bevy/latest/bevy/ecs/relationship/trait.Relationship.html#method.on_replace

> Register a ComponentHook that will be run when this component is about to be dropped, such as being replaced (with .insert) or removed.

So I asked in Discord, #ecs

> Can I expect it to be run whenever a component is removed, regardless of whether it's being replaced?
>
> I came to this because I'm implementing a custom Relationship, and I saw that trait Relationship provides `on_insert` and `on_replace`. So is `on_remove` not needed, as `on_replace` runs anyway, regardless of whether the component is actually being replaced?

Tim kindly answered

> Yes, it is run when the component is removed, and yes the naming here is very confusing
> As far as I can tell the actual on_remove hook is useless for any kind of bookeeping

So, I think the docs for this method should be improved so they're less confusing. I still don't understand what it's for / how it works in enough detail to propose better docs.

An alternative would be to choose a better name for the method. Perhaps `on_removing` would be clearer, as it expresses "yes it's being removed" and "the removal is kind of in-progress, so you can still get at stuff"

Contributor guide

Open the contributing guide

Research direction

Start with the linked docs.rs page for Relationship::on_replace and read the surrounding on_insert and on_remove documentation. Trace the hook's removal and replacement semantics in the Relationship trait and related ECS behavior, then update the method documentation or naming so its timing and purpose are unambiguous.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
documentation
Issue type
Documentation
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.