Closed BronzedMocha closed 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.
I understand your approach here. Strictly minimizing control to the value of a Hold or Group object itself is a great way to enforce a specific structure that further reduces potential bugs in all use cases at once. Allowing for changes in the graph dependency can release a plethora of bugs and threatens the reliability of the individual state objects.
And you still plan to allow Wraps to accept signals directly as well as through other Holds?
And you still plan to allow Wraps to accept signals directly as well as through other Holds?
Yes, I am. Perhaps I haven't made it clear, but Wraps will accept both state objects (any object that can be read from), and raw data (which in our case, signals).
Closed in favor of #19.
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.