Skip to content

Split States into their own crate, and add convenience app extension methods #7906

@alice-i-cecile

Description

@alice-i-cecile

What problem does this solve or what need does it fill?

Bevy states are well-isolated from other app or ECS logic, and not all users will want to use our exact implementation (e.g. some users may want a state stack).

Adding dedicated methods to manage and work with states to both bevy_app and bevy_ecs feels "wrong" as a result: it ends up polluting APIs with what could reasonably be an add-on.

What solution would you like?

  1. Create a new bevy_states crate.
  2. Move all core state logic out of bevy_ecs.
  3. Move App::add_state out of bevy_app onto an extension trait.
  4. Add .on_update, .on_enter and .on_exit system modifiers via an extension trait.
  5. Depend on bevy_states in bevy_core as an optional dependency and add the extension traits and structs back to the prelude.

What alternative(s) have you considered?

If we want to replace startup systems with states as in #5437, we should be able to retain this design, and simply import bevy_states in bevy_core.

Additional context

This was proposed by @maniwani in #7790 here, which attempted to add sugar for on_update.

#7634 is also something to be mindful of during the implementation.

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-AppBevy apps and pluginsA-ECSEntities, components, systems, and eventsC-Code-QualityA section of code that is hard to understand or changeC-UsabilityA targeted quality-of-life change that makes Bevy easier to useM-Needs-Migration-GuideA breaking change to Bevy's public API that needs to be noted in a migration guideX-ControversialThere is active debate or serious implications around merging this PR

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions