sinlerdev
commented
1 year ago I have been thinking a lot about rewriting Wrap, as it seems a bit impractical when you actually use it, not because of the issue you are describing, but rather how Wrap's API has been designed.
As for a fix for this issue, I think we should allow Wraps to accept a state object that return signals as their first argument, and when the said object updates, the Wrap will reinitialize.
This will certainly require you to do some work on your own (such as listening for when the owner of such event comes to existence), although these can be done in a companion library very easily.
Regarding the last paragraph of your issue, I don't think that a "general" replacing mechanism is any useful at all, as after all, the "start" of a datamodel graph is either a Hold or a group because those are the objects you want to store state, that you completely manage.
As such, you don't need to do any "replacing" mechanism just for a use case like this, because you already have the ability to change Holds/Groups' values to something else.
BronzedMocha
Reflecting the player's health to a state object with Wrap is presented consistently as a use-case for Vinum, but since Humanoids will constantly get destroyed and recreated it's impractical to use a Wrap to track it as you'll still need to handle cleanup, and somehow get all the depending states the correct data. If there were some way to set the dependency of a Hold object to another script signal, then one single Wrap object could better reflect any recreated RBXScriptSignal.
in a more general sense, some way to use the same state object while replacing it with other references/dependencies would serve as a huge quality-of-life improvement for managing state objects at a large scale.