Wrap, in its own current form, is extremely limited- as its only useful for events that are fired with something. However, it's obvious that there are some events that don't fire with stuff, that still have a value- most notably the famous button clicks counter showcase in any framework that touches reactivity with instances.
Another issue that was brought up by someone (see #17), is that sometimes, the events we are using for Wraps can get disconnected as a reaction to the said event's owner destruction. A solution for this is to make Wraps accept either a pure signal, or a signal stored in a state object.
An additional issue that I just thought of was how we created wrap objects. Currently, we create an entire object for each param- and while that is "good" on paper, it falls apart when we need cross-processing between params.
I have a new design in mind, which I think solves all of these issues. The said design is:
local buttonClickedEvent = Hold(ButtonClicked, AlwaysTrue) -- this event doesn't fire with any argument
local wrapped = Wrap(buttonClickedEvent, {0, false}, function(lastClicks, numOfClicksIsEven)
return lastClicks + 1, isEven(lastClicks + 1)
end)
read(wrapped, 1) -- refers to lastClicks, as its index is 1
Wrap, in its own current form, is extremely limited- as its only useful for events that are fired with something. However, it's obvious that there are some events that don't fire with stuff, that still have a value- most notably the famous button clicks counter showcase in any framework that touches reactivity with instances.
Another issue that was brought up by someone (see #17), is that sometimes, the events we are using for Wraps can get disconnected as a reaction to the said event's owner destruction. A solution for this is to make Wraps accept either a pure signal, or a signal stored in a state object.
An additional issue that I just thought of was how we created wrap objects. Currently, we create an entire object for each param- and while that is "good" on paper, it falls apart when we need cross-processing between params.
I have a new design in mind, which I think solves all of these issues. The said design is: