Objective

The proposed "Resources as entities" PR makes Resource implement Component. This creates a situation where we need to do:

#[derive(Resource, Reflect)]
#[reflect(Resource, Component)]
struct Thing;

I'm of the mind that we should add the ability for TypeData to have "dependencies". Ex reflect(Resource) implies reflect(Component). For "subtrait" types, I think supporting this is logical / users would appreciate it.

Solution

1. Add a new FromType<T>::insert_dependencies function with a default impl (which makes this a non-breaking change). This does kind of overload the FromType trait (ex: a name like GetTypeData might be better with this new context), but this is a pretty niche trait / piece of functionality, and I like the idea of not breaking people.
2. Add a new TypeRegistration::register_type_data<T, V> function, which initializes the TypeData T for a given type V , inserts that type data, and also inserts any dependent type data using insert_dependencies.
3. Adjust the Reflect macro to use register_type_data instead of insert(FromType::<Self>::from_type())

This makes it possible to do the following:

impl<R: Resource + FromReflect + TypePath> FromType<R> for ReflectResource {
    fn from_type() -> Self {
        ReflectResource
    }

    fn insert_dependencies(type_registration: &mut TypeRegistration) {
        type_registration.register_type_data::<ReflectComponent, R>();
    }
}

Which then allows dropping reflect(Component):

#[derive(Resource, Reflect)]
#[reflect(Resource)]
struct Thing;

Testing

I added a unit test 😜