replace FromWorld with FromReflect in ReflectComponent, ReflectResource

[jakobhellermann]

Objective

There should be no need for components and resources to implement FromWorld just for accessing and inserting them into the world.

Solution

• replace T: FromWorld and let component = T::from_world(world); component.apply(value); with T: FromReflect and let component = T::from_reflect(value);

Changelog

• require FromReflect instead of FromWorld for #[reflect(Component)] and #[reflect(Resource)]

Migration Guide

If you used #[reflect(Component)] or #[reflect(Resource)] you now need a #[derive(FromReflect)] as well, but the FromWorld (or Default) impl can go away.

[jakobhellermann]

Rebased and fixed review comments

[jakobhellermann]

This now fails because the FromReflect impl of ComponentB in the scene.rs example isn't used anymore:

bevy/examples/scene/scene.rs

Line 49 in fe7ebd4

impl FromWorld for ComponentB {

@MrGVSV any thoughts on this? If scene loading should be able to provide defaults with world access, I feel like that shouldn't go through ReflectComponent but through another mechanism.

[MrGVSV]

@MrGVSV any thoughts on this? If scene loading should be able to provide defaults with world access, I feel like that shouldn't go through ReflectComponent but through another mechanism.

Hm, this is something I've been wondering myself actually. There's not a great workaround I found to allow this. Maybe using something like #6055 to generalize on FromReflect but specialize on FromWorld?

[halbe]

I have a situation where there is no suitable implementation of Default or FromWorld for my component. I am working on Bevy's IK system which needs to store a reference to another entity to use as an IK target. I need to be able to have this component get inserted at runtime into a scene representing a character so that you can spawn characters with their IK system, but the type registry requires that either FromWorld or Default be implemented in this scenario even though I am only inserting it with all of its fields explicitly specified.

I can make it an Option for now, but you shouldn't have an IK without a target, it will simply not do anything. The appropriate way to enable/disable it would be to change the number of iterations to 0, not removing its target. The IK target should also be an entity instead of storing a transform inside of the IkJoint so that you can manipulate the target itself with another target or a hierarchy, riggers do this quite often.

[MrGVSV]

Superseded by #9623