GetPropertyChangedSignal Should Fire with Arguments

[cxmeels]

I believe Roblox could improve upon the current implementation of the GetPropertyChangedSignal method by firing the event with two arguments; one representing the old value, and one representing the new.

This allows us as developers to track changes in properties easier, as we will no longer need to observe an externally created variable for holding the previous value.

For those looking to implement things such as anti-cheats, this would benefit them, as it’ll be easier to watch for changes in the player’s position, for example.

Character.PrimaryPart:GetPropertyChangedSignal("Position"):Connect(function(oldPosition, newPosition)
    local distance = (newPosition - oldPosition).magnitude

    if distance > 16 then
        Character.PrimaryPart.Position = oldPosition
    end
end)

While I’m aware it’s very easy to implement variables or wrappers manually, I believe it’d be of greater convenience to append these to the existing event.

[Halalaluyafail3 (FindFirstChild)]

GetPropertyChangedSignal should include the new value in the callback

As a developer, it is too hard to not write redundant code with GetPropertyChangedSignal. With GetPropertyChangedSignal, there aren’t very many scenarios where you wouldn’t want to know what the property actually changed to. For example, if I want to write code that does something when the player’s team changes, I have to write it like this. LocalPlayer:GetPropertyChangedSignal("Team"):Connect(function() local team = LocalPlayer.Team --code end) I’d much rather simplify this to be… L…

@cxmeels

Character.PrimaryPart:GetPropertyChangedSignal("Position"):Connect(function(oldPosition, newPosition)
    local distance = (newPosition - oldPosition).magnitude

    if distance > 16 then
        Character.PrimaryPart.Position = oldPosition
    end
end)

Changed events don’t fire for physics, so this seems like a bad example. Setting position on the PrimaryPart also doesn’t move the entire character, it will only move PrimaryPart and adjust the offsets of the joints to keep the other parts in the same position.

[cxmeels]

My bad. I didn’t realise physics didn’t fire change events. I guess ValueBases or UI objects would be a better example.

As for that other thread, it wasn’t suggested when I wrote the topic, but I do believe we need the old value in addition to the new. Rodux and Roact both respond with the old and new values in their update events, so it’d be nice if it was a feature in the engine itself for change events.