-
-
Notifications
You must be signed in to change notification settings - Fork 3.3k
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
Restore overwrite capabilities of insert_state
#13848
Conversation
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 prefer to add a regression test too but I like this fix.
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.
Approving with a minor nit and a couple ignorable comments.
@@ -70,6 +71,9 @@ impl AppExtStates for SubApp { | |||
exited: None, | |||
entered: Some(state), | |||
}); | |||
} else { | |||
let name = std::any::type_name::<S>(); | |||
warn!("State {} is already initialized.", name); |
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 suppose this is reasonable, although .init_resource
doesn't warn for this.
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.
Probably should 😅
@@ -87,6 +91,16 @@ impl AppExtStates for SubApp { | |||
exited: None, | |||
entered: Some(state), | |||
}); | |||
} else { | |||
// Overwrite previous state and setup event | |||
self.insert_resource::<State<S>>(State::new(state.clone())); |
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.
Noting that there's some duplication between the two branches of the if-else
. Pulling them out of the if-else
would probably hurt readability, so I won't suggest that :)
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.
There is a lot of overlap between all the state methods, we can do a cleanup PR later trying to factorize out the common parts
# Objective - Fixes #13844 - Warn user when initializing state multiple times ## Solution - `insert_state` will overwrite previously initialized state value, reset transition events and re-insert it's own transition event. - `init_state`, `add_sub_state`, `add_computed_state` are idempotent, so calling them multiple times will emit a warning. ## Testing - 2 tests confirming overwrite works. - Given the example from #13844 ```rs use bevy::prelude::*; fn main() { App::new() .add_plugins(DefaultPlugins) .insert_state(AppState::A) .insert_state(AppState::B) .add_systems(OnEnter(AppState::A), setup_a) .add_systems(OnEnter(AppState::B), setup_b) .add_systems(OnExit(AppState::A), cleanup_a) .add_systems(OnExit(AppState::B), cleanup_b) .run(); } #[derive(States, Debug, Clone, PartialEq, Eq, Hash)] enum AppState { A, B, } fn setup_a() { info!("setting up A"); } fn setup_b() { info!("setting up B"); } fn cleanup_a() { info!("cleaning up A"); } fn cleanup_b() { info!("cleaning up B"); } ``` We get the following result: ``` INFO states: setting up B ``` which matches our expectations.
Objective
Solution
insert_state
will overwrite previously initialized state value, reset transition events and re-insert it's own transition event.init_state
,add_sub_state
,add_computed_state
are idempotent, so calling them multiple times will emit a warning.Testing
We get the following result:
which matches our expectations.