Move AppTypeRegistry to bevy_ecs

[nicopap]

Objective

• Use AppTypeRegistry on API defined in bevy_ecs (implement insert and remove reflected entity commands #8895 (comment))

A lot of the API on Reflect depends on a registry. When it comes to the ECS. We should use AppTypeRegistry in the general case.

This is however impossible in bevy_ecs, since AppTypeRegistry is defined in bevy_app.

Solution

• Move AppTypeRegistry resource definition from bevy_app to bevy_ecs
• Still add the resource in the App plugin, since bevy_ecs itself doesn't know of plugins

Note that bevy_ecs is a dependency of bevy_app, so nothing revolutionary happens.

Alternative

• Define the API as a trait in bevy_app over bevy_ecs. (though this prevents us from using bevy_ecs internals)
• Do not rely on AppTypeRegistry for the API in question, requring users to extract themselves the resource and pass it to the API methods.

---

Changelog

• Moved AppTypeRegistry resource definition from bevy_app to bevy_ecs

Migration Guide

• If you were not using a prelude::* to import AppTypeRegistry, you should update your imports:

- use bevy::app::AppTypeRegistry;
+ use bevy::ecs::reflect::AppTypeRegistry

[alice-i-cecile]

TypeRegistryArc is a Arc<RwLock>, which means even mutable

This sentence seems incomplete :)

[alice-i-cecile]

I don't love the name still, but this is a very simple migration :)

[nicopap]

TypeRegistryArc is a Arc, which means even mutable

This sentence seems incomplete :)

Ooops. I realized it should implement DerefMut in the middle of making that sentence and went back to add the impl. But forgot to remove the sentence.

[MrGVSV]

We could consider calling this WorldTypeRegistry since we're moving it to ECS and it should exist in the world. But we can also hold off on that for a future PR.

[nicopap]

I don't want to include it in this PR. Changing the name is way more breaking than changing the crate it's defined in, as people will usually import it through prelude::*. Basically most users wouldn't need to change a line with this. While renaming it would require a bit more work. I think it's the kind of change that deserves a bit more scrutiny, even if I'm for it.

[MrGVSV]

Agreed!

[MrGVSV]

QQ: These won't mess with cloning right? Does this still work?

fn system(registry: Res<AppTypeRegistry>) {
  let registry2: AppTypeRegistry = registry.into_inner().clone();
}

[nicopap]

It was implementing Deref and DerefMut through the bevy_derive::Deref{,Mut} macro before. So it should reproduce the same behavior. The macro basically writes this code.

[MrGVSV]

Ah I missed that part. Awesome, sounds good!

[MrGVSV]

Should we default a world to include this resource (under bevy_reflect feature)? Or is it still the responsibility of the user/bevy_app to initialize it?

I'm guessing the latter, but just want to clarify.

[nicopap]

That's an interesting proposition. I like the idea. Though I'm curious of the implications with regard to Scenes for example.

[alice-i-cecile]

We should avoid automatically inserting resources whenever possible :)