Remove .onChange events for state objects about fusion

[boatbomber]

I use .onChange quite a bit, and would be sad to see this functionality go. It's very useful.

What if we had State:OnChange(callback) instead so that the State object is given the function and can handle it better, calling and clearing as needed.

[dphfox]

One API design I'm currently considering is introducing a new reactive object, Compat, which lets you watch for these kinds of lifecycle events that shouldn't normally be used in Fusion code:

local numCoins = State(50)
local doubleCoins = Computed(function() return numCoins:get() * 2 end)

local compat = Compat(doubleCoins)
local disconnect = compat:onChange(function()
    print("doubleCoins has changed")
end)

(this isn't a final API design by the way, it's just a vague idea that took me 5 minutes to come up with)

This is, technically speaking, not really different from onChange - it has the same uses and problems. However, there's benefits to adding this intermediate step:

• reactive objects (State/Computed/ComputedPairs/Tween/Spring) no longer have to maintain their own implementation of onChange - there's now just one implementation inside Compat
• the name 'Compat' shows that this API is intended for making non-Fusion UIs compatible with Fusion, rather than presenting itself as an API intended for common use
• it adds friction to the process of using these events, which can push developers towards the simpler and cleaner reactive solutions; not all APIs should be frictionless to use!

Of course, this is very much a work in progress, and I'd love to hear more feedback around this.

[BPilot253]

This seems like a much nicer alternative of “embedded”onChange, especially since it can be used with non-Fusion UIs.
This also means onChange won’t exist when it’s not needed, which I guess is great?

I’m 100% for this change.

[dphfox]

I'm wondering if it's worth shipping the first experimental version of Fusion without support for this use case?

[dphfox]

After further investigation this is definitely important enough to support, because it's a vital part of getting non-Fusion UI and Fusion UI to work together.

To be more specific about the kinds of anti-patterns I've noticed onChange causes, take this code example:

local numCoins = State(50)

local doubleCoins = State(numCoins:get() * 2)
numCoins.onChange:Connect(function()
    doubleCoins:set(numCoins:get() * 2)
end)

In the above code, the developer was attempting to express a relationship between doubleCoins and numCoins - specifically, they were trying to say "doubleCoins should always be numCoins * 2".

While the above code works, it's smelly:

• wet - we're writing the same calculation twice, and they need to be identical. However, we could accidentally forget to change one, or make a typo, or introduce some other discrepancy.
• implicit - the relationship between the two objects is not explicit. Because we're handling updating doubleCoins ourselves, Fusion can't see that it's directly dependent on numCoins, and so can't optimise.
• writable - even though we should only set doubleCoins to numCoins * 2, and we expect it to equal that all the time, it's still possible for another part of the code to set it to another unrelated value and break everything.

Fusion already has a far better object for expressing these kinds of relationships cleanly, explicitly and safely: computed objects. The above example can be written much more cleanly using a computed object:

local numCoins = State(50)

local doubleCoins = Computed(function()
    return numCoins:get() * 2
end)

This is much less smelly:

• dry - we only write the calculation once, so we can't accidentally mess it up
• explicit - Fusion can now detect and optimise the dependency on numCoins, making this faster to update
• read-only - computed objects can't be written to, so the above relationship is guaranteed to always hold

This is an example of where .onChange has allowed for developers to write less sound code by accident. I consider this to be a failure of API design; it's too easy and enticing to use onChange rather than using a proper reactive solution.

I think, if I replace this with another API, it needs to explicitly and visibly be for compatibility with non-Fusion code. It shouldn't appear next to reactive objects as .onChange does now, because that makes it seem like it's alright to mix in with reactive code. In reality, that's rarely the case, and a reactive solution exists and works better.

[dphfox]

Made the change 🎉