I typically use the same system that Lyra uses, which is to use replicated UObjects (or non-replicated if single player of course). This allows you to have a dynamic system which encases any type of item you need. With this method, you do not care about the data structure of each varying item type because the object itself handles it. If all items are not going to be derived from a base item class, interface functionality can be used to fill the gaps and get whatever data is needed regardless of the class. Now the rest is up to the implementer, but I generally attach the UObject holding the data to the actor. When it comes to equipping and using the item itself, I don’t actually spawn the actor in hand, but spoof it with just attaching the visual mesh to the player. The only time I would really spawn an actor is if I am dropping the item on the floor, or if it directly placed into the world as a pickup item. The reason being is SpawnActor is costly, and when I am spawning actors, I always use some form of optimization like pooling.
Edit: The only other caveat to this is in multiplayer, where a replicated UObject needs an Actor channel to replicate through. So when an Item Actor is destroyed with its UObject data, I generally just make a copy of the UObject to place in the inventory, making the new actor channel to use the player pawn rather than the Item Actor since it will be destroyed (and therefore wouldn’t allow the UObject to replicate properly).