Sure it’s just a couple of markups:
First is your UMyThing:
UCLASS( EditInlineNew )
class UMyThing : public UObject
...
Then in your MyHolder class:
UPROPERTY( Edit***, Instanced )
UMyThing* VarName;
UPROPERTY( Edit***, Instanced )
TArray< UMyThing* > CollectionName;
In the editor for a UMyThing asset in the Editor, you’ll get a dropdown for the members with the Instanced markup. That dropdown will list every class that derives from UMyThing (you can exclude classes a few ways, but the most useful one is using Abstract in the UCLASS). When you select a type from that dropdown, it will create an instance of that type and add a small section that is all the properties of the selected type (similar to how structures are shown). If UMyThing were blueprintable, you’d be able to make blueprint types and they would also show up in the drop down. But because of the markup required, the base class used for instanced properties and the properties themselves need to be defined in C++ even if the instanced type picked in the Editor is a blueprint one.
You can also now do something similar with TInstancedStructs. It’s a little easier because it doesn’t need any markup. You just make a new USTRUCT, make a bunch of USTRUCTs that derive from it and then declare properties with TInstancedStruct< FBaseType > as the variable type. But the usual structure limitations come into play.
Lastly it’s worth mentioning that this can be very powerful for configuring things, but is best for things that are meant to be unique across instances. Benbyy’s suggestion of creating assets and referencing them is also a strong solution when multiple objects really want to share details.
For example, our game had abilities (no big surprise) which would be your UMyHolder. It had an array of instanced objects for the effects that it would cause (because those effects were meant to be configured uniquely on each ability). But if the effect where applying a status effect, instanced of it having another instanced object, it had a reference to another data asset. Because every ability that applies Stun should apply the same Stun.
So instanced objects aren’t meant to replace or be better advice, just another tool in the toolbox.