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

bevy_reflect uses TypeRegistry to keep track of metadata used to dynamic interact with Reflect types. This is also used by ser/de operations, like bevy_scene and any networking.

Users should keep a reference to a single TypeRegistry that contains all types registered and pass it around to Scenes, ReflectSerializer, *ReflectDeserializer and any type which needs to deal with its metadata, which is very verbose to carry around.

Also this make it hard to have custom ReflectSerialize and ReflectDeserialize implementations, since there is no TypeRegistry available, where in this case, users should make the TypeRegistry global available themselves.

Usually the TypeRegistry is written once, at the App startup, either by plugins or by any custom logic, and then read by any bevy_reflect operations which needs to know it's metadata.

What solution would you like?

Add a default global available TypeRegistry, to be used when a single TypeRegistry is required (which should cover most use cases), but keep TypeRegistry to be instantiated and be used individually when required (something like ReflectSerializer::with_registry).

1. Make TypeRegistry global available;
2. Change ReflectSerializer/*ReflectDeserializer; to use global TypeRegistry by default;
3. Add an option to use a custom TypeRegistry on:
   1. ReflectSerializer;
   2. *ReflectDeserializer;

What alternative(s) have you considered?

Let users create a global available TypeRegistry, to be built after app startup and use it. This will solve the problem of accessing TypeRegistry inside a custom ReflectSerialize/ReflectDeserialize but keeping the verbosity of carrying around the TypeRegistry.

Additional context

I'll do some researches on this subject, but there are some questions which needs to be solved, mostly to know how far should we go with this enhancement:

• 1. Should we change DynamicScene to also use global TypeRegistry by default?
• 2. Should we remove the App::register_type in favor of a static TypeRegistry::register_type?
• 3. Should we remove the resource TypeRegistry from App?

Also, another questions to be answered:

• 1. There are some use cases where multiple TypeRegistry should be kept around?
• 2. There are some use cases where new types will be registered, after the app startup stage?