
# Objective - Fixes #17960 ## Solution - Followed the [edition upgrade guide](https://doc.rust-lang.org/edition-guide/editions/transitioning-an-existing-project-to-a-new-edition.html) ## Testing - CI --- ## Summary of Changes ### Documentation Indentation When using lists in documentation, proper indentation is now linted for. This means subsequent lines within the same list item must start at the same indentation level as the item. ```rust /* Valid */ /// - Item 1 /// Run-on sentence. /// - Item 2 struct Foo; /* Invalid */ /// - Item 1 /// Run-on sentence. /// - Item 2 struct Foo; ``` ### Implicit `!` to `()` Conversion `!` (the never return type, returned by `panic!`, etc.) no longer implicitly converts to `()`. This is particularly painful for systems with `todo!` or `panic!` statements, as they will no longer be functions returning `()` (or `Result<()>`), making them invalid systems for functions like `add_systems`. The ideal fix would be to accept functions returning `!` (or rather, _not_ returning), but this is blocked on the [stabilisation of the `!` type itself](https://doc.rust-lang.org/std/primitive.never.html), which is not done. The "simple" fix would be to add an explicit `-> ()` to system signatures (e.g., `|| { todo!() }` becomes `|| -> () { todo!() }`). However, this is _also_ banned, as there is an existing lint which (IMO, incorrectly) marks this as an unnecessary annotation. So, the "fix" (read: workaround) is to put these kinds of `|| -> ! { ... }` closuers into variables and give the variable an explicit type (e.g., `fn()`). ```rust // Valid let system: fn() = || todo!("Not implemented yet!"); app.add_systems(..., system); // Invalid app.add_systems(..., || todo!("Not implemented yet!")); ``` ### Temporary Variable Lifetimes The order in which temporary variables are dropped has changed. The simple fix here is _usually_ to just assign temporaries to a named variable before use. ### `gen` is a keyword We can no longer use the name `gen` as it is reserved for a future generator syntax. This involved replacing uses of the name `gen` with `r#gen` (the raw-identifier syntax). ### Formatting has changed Use statements have had the order of imports changed, causing a substantial +/-3,000 diff when applied. For now, I have opted-out of this change by amending `rustfmt.toml` ```toml style_edition = "2021" ``` This preserves the original formatting for now, reducing the size of this PR. It would be a simple followup to update this to 2024 and run `cargo fmt`. ### New `use<>` Opt-Out Syntax Lifetimes are now implicitly included in RPIT types. There was a handful of instances where it needed to be added to satisfy the borrow checker, but there may be more cases where it _should_ be added to avoid breakages in user code. ### `MyUnitStruct { .. }` is an invalid pattern Previously, you could match against unit structs (and unit enum variants) with a `{ .. }` destructuring. This is no longer valid. ### Pretty much every use of `ref` and `mut` are gone Pattern binding has changed to the point where these terms are largely unused now. They still serve a purpose, but it is far more niche now. ### `iter::repeat(...).take(...)` is bad New lint recommends using the more explicit `iter::repeat_n(..., ...)` instead. ## Migration Guide The lifetimes of functions using return-position impl-trait (RPIT) are likely _more_ conservative than they had been previously. If you encounter lifetime issues with such a function, please create an issue to investigate the addition of `+ use<...>`. ## Notes - Check the individual commits for a clearer breakdown for what _actually_ changed. --------- Co-authored-by: François Mockers <francois.mockers@vleue.com>
147 lines
5.8 KiB
Rust
147 lines
5.8 KiB
Rust
//! This example illustrates the different ways you can employ component lifecycle hooks.
|
|
//!
|
|
//! Whenever possible, prefer using Bevy's change detection or Events for reacting to component changes.
|
|
//! Events generally offer better performance and more flexible integration into Bevy's systems.
|
|
//! Hooks are useful to enforce correctness but have limitations (only one hook per component,
|
|
//! less ergonomic than events).
|
|
//!
|
|
//! Here are some cases where components hooks might be necessary:
|
|
//!
|
|
//! - Maintaining indexes: If you need to keep custom data structures (like a spatial index) in
|
|
//! sync with the addition/removal of components.
|
|
//!
|
|
//! - Enforcing structural rules: When you have systems that depend on specific relationships
|
|
//! between components (like hierarchies or parent-child links) and need to maintain correctness.
|
|
|
|
use bevy::{
|
|
ecs::component::{ComponentHook, HookContext, Mutable, StorageType},
|
|
prelude::*,
|
|
};
|
|
use std::collections::HashMap;
|
|
|
|
#[derive(Debug)]
|
|
/// Hooks can also be registered during component initialization by
|
|
/// using [`Component`] derive macro:
|
|
/// ```no_run
|
|
/// #[derive(Component)]
|
|
/// #[component(on_add = ..., on_insert = ..., on_replace = ..., on_remove = ...)]
|
|
/// ```
|
|
struct MyComponent(KeyCode);
|
|
|
|
impl Component for MyComponent {
|
|
const STORAGE_TYPE: StorageType = StorageType::Table;
|
|
type Mutability = Mutable;
|
|
|
|
/// Hooks can also be registered during component initialization by
|
|
/// implementing the associated method
|
|
fn on_add() -> Option<ComponentHook> {
|
|
// We don't have an `on_add` hook so we'll just return None.
|
|
// Note that this is the default behavior when not implementing a hook.
|
|
None
|
|
}
|
|
}
|
|
|
|
#[derive(Resource, Default, Debug, Deref, DerefMut)]
|
|
struct MyComponentIndex(HashMap<KeyCode, Entity>);
|
|
|
|
#[derive(Event)]
|
|
struct MyEvent;
|
|
|
|
fn main() {
|
|
App::new()
|
|
.add_plugins(DefaultPlugins)
|
|
.add_systems(Startup, setup)
|
|
.add_systems(Update, trigger_hooks)
|
|
.init_resource::<MyComponentIndex>()
|
|
.add_event::<MyEvent>()
|
|
.run();
|
|
}
|
|
|
|
fn setup(world: &mut World) {
|
|
// In order to register component hooks the component must:
|
|
// - not be currently in use by any entities in the world
|
|
// - not already have a hook of that kind registered
|
|
// This is to prevent overriding hooks defined in plugins and other crates as well as keeping things fast
|
|
world
|
|
.register_component_hooks::<MyComponent>()
|
|
// There are 4 component lifecycle hooks: `on_add`, `on_insert`, `on_replace` and `on_remove`
|
|
// A hook has 2 arguments:
|
|
// - a `DeferredWorld`, this allows access to resource and component data as well as `Commands`
|
|
// - a `HookContext`, this provides access to the following contextual information:
|
|
// - the entity that triggered the hook
|
|
// - the component id of the triggering component, this is mostly used for dynamic components
|
|
// - the location of the code that caused the hook to trigger
|
|
//
|
|
// `on_add` will trigger when a component is inserted onto an entity without it
|
|
.on_add(
|
|
|mut world,
|
|
HookContext {
|
|
entity,
|
|
component_id,
|
|
caller,
|
|
}| {
|
|
// You can access component data from within the hook
|
|
let value = world.get::<MyComponent>(entity).unwrap().0;
|
|
println!(
|
|
"{component_id:?} added to {entity} with value {value:?}{}",
|
|
caller
|
|
.map(|location| format!("due to {location}"))
|
|
.unwrap_or_default()
|
|
);
|
|
// Or access resources
|
|
world
|
|
.resource_mut::<MyComponentIndex>()
|
|
.insert(value, entity);
|
|
// Or send events
|
|
world.send_event(MyEvent);
|
|
},
|
|
)
|
|
// `on_insert` will trigger when a component is inserted onto an entity,
|
|
// regardless of whether or not it already had it and after `on_add` if it ran
|
|
.on_insert(|world, _| {
|
|
println!("Current Index: {:?}", world.resource::<MyComponentIndex>());
|
|
})
|
|
// `on_replace` will trigger when a component is inserted onto an entity that already had it,
|
|
// and runs before the value is replaced.
|
|
// Also triggers when a component is removed from an entity, and runs before `on_remove`
|
|
.on_replace(|mut world, context| {
|
|
let value = world.get::<MyComponent>(context.entity).unwrap().0;
|
|
world.resource_mut::<MyComponentIndex>().remove(&value);
|
|
})
|
|
// `on_remove` will trigger when a component is removed from an entity,
|
|
// since it runs before the component is removed you can still access the component data
|
|
.on_remove(
|
|
|mut world,
|
|
HookContext {
|
|
entity,
|
|
component_id,
|
|
caller,
|
|
}| {
|
|
let value = world.get::<MyComponent>(entity).unwrap().0;
|
|
println!(
|
|
"{component_id:?} removed from {entity} with value {value:?}{}",
|
|
caller
|
|
.map(|location| format!("due to {location}"))
|
|
.unwrap_or_default()
|
|
);
|
|
// You can also issue commands through `.commands()`
|
|
world.commands().entity(entity).despawn();
|
|
},
|
|
);
|
|
}
|
|
|
|
fn trigger_hooks(
|
|
mut commands: Commands,
|
|
keys: Res<ButtonInput<KeyCode>>,
|
|
index: Res<MyComponentIndex>,
|
|
) {
|
|
for (key, entity) in index.iter() {
|
|
if !keys.pressed(*key) {
|
|
commands.entity(*entity).remove::<MyComponent>();
|
|
}
|
|
}
|
|
for key in keys.get_just_pressed() {
|
|
commands.spawn(MyComponent(*key));
|
|
}
|
|
}
|