-
-
Notifications
You must be signed in to change notification settings - Fork 3.2k
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
Schedule resource mutation #13193
Schedule resource mutation #13193
Conversation
…dd systems to either an existing or new schedule with a call to "add_systems"
note - no test was added since there wasn't an example of using it, and I am not familiar enough with it's effects to know how to set up that test
…le_resource_mutation
…ll to the method on the `Schedules` resource
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 agree with moving these up a level. Nice and simple and a more reasonable API.
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.
This is a good change. There was very little reason for these methods to be exlusive to bevy_app.
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.
LGTM
Objective
Resolves #13185
Solution
Move the following methods from
sub_app
to theSchedules
resource, and use them in the sub app:add_systems
configure_sets
ignore_ambiguity
Add an
entry(&mut self, label: impl ScheduleLabel) -> &mut Schedule
method to theSchedules
resource, which returns a mutable reference to the schedule associated with the label, and creates one if it doesn't already exist. (build on top of theentry(..).or_insert_with(...)
pattern inHashMap
.Testing
schedule.rs
- one that validates adding a system to an existing schedule, one that validates adding a system to a new one, one that validates configuring sets on an existing schedule, and one that validates configuring sets on a new schedule.entry
since the previous 4 tests use functions that rely on it.ignore_ambiguity
since I didn't see examples of it's use, and am not familiar enough with it to know how to set up a good test for it. However, it relies on theentry
method as well, so it should work just like the other 2 methods.