Allow TweenInfo parameters to be modified after creating the object

Hey everyone,

As a Roblox developer, it is currently difficult to apply TweenInfo settings conveniently. It is mandatory to include the arguments right then and there which means you cannot mutate them afterwards. With RaycastParams, for example, you can mutate the object properties after it has been created:

-- taken from DevHub
local raycastParams = RaycastParams.new()
raycastParams.FilterType = Enum.RaycastFilterType.Whitelist
raycastParams.FilterDescendantsInstances = {workspace.Model}
raycastParams.IgnoreWater = true

This is very convenient as you do not need to remember the order of parameters in the constructor and default values take precedence unless changed. With TweenInfo, I propose that we should have this ability on top of traditionally inputting arguments. Something like:

-- doing this right now errors with "X cannot be assigned to"
local tweenInfo = TweenInfo.new(5, Enum.EasingStyle.Linear) -- arguments here still allowed
tweenInfo.Reverses = true 
tweenInfo.DelayTime = 1

Reverses and DelayTime are the last parameters. All parameters have default values, but if I want to modify those last parameters, I’d have to give the values of the already defaulted parameters to get there, like so:

-- all except the last two are default values
local tweenInfo = TweenInfo.new(
    1,
    Enum.EasingStyle.Quad,
    Enum.EasingDirection.Out, 
    0,
    true, -- reverses: NOT default
    1 -- delay time: NOT default
)

This is an absolute bloat and not everyone may remember the order of parameters (I often get mixed up with EasingStyle and EasingDirection, which forces me an unnecessary DevHub dive).

If this were added, it’d improve my development experience because I can easily modify TweenInfo parameters without having to go through the hassle of providing a huge tuple all the time. The current behavior will stay, of course, for convenience (in certain other cases) and compatibility. Plus, since there are default values for these parameters already in place, this new design fits perfectly with it.

Thank you.

18 Likes

This would change how TweenInfo would be considered, as TweenInfo would now be a mutable object. TweenInfo properties (namely Tween.TweenInfo) would have surprising behavior if you tried to modify the temporary object returned by getting the property.

local t = Instance.new"Tween"
t.TweenInfo.Reverses = true -- silently does nothing

If the property can’t be written to, then it won’t generate an error as if you tried to assign directly to the TweenInfo property. If the property can be written to, then it will do nothing when modification was intended which is very unexpected (and it looks like the property is being changed, too).

A better solution would be to have a TweenParams which acts like what you want, it would avoid the problem of setting properties on the temporary TweenInfo returned when reading a TweenInfo property. TweenParams could also have a constructor like TweenParams.fromInfo(TweenInfo) (and obviously TweenParams.new()) and TweenInfo could have a constructor like TweenInfo.fromParams(TweenParams). Perhaps TweenService:Create could allow passing a TweenParams too. Having a distinction between TweenParams and TweenInfo isn’t that great either, but it would be better than having surprising behavior described before.

7 Likes

Yea would be amazing if you could write to a TweenInfo
So i don’t have to create another Tween Info to change one value.

Or even writing to a Tween Instance
this would open up a lot of possibilities in terms of Tweening

1 Like

Support for this. The same can be suggested about other objects like Vectors. (being able to modify the X, Y, and Z properties after creation rather than creating a completely new vector, clogging memory with garbage)

1 Like

Agreed,
had once to re-create the tween info twice,
would be nice if they could change it

1 Like

Support, would make things a bit easier

its kinda wierd and outdated how you can’t edit a tweeninfo after it was made

TweenInfo needs some upgrading, agreed.

Also sending TweenInfo over a RemoteEvent and having it not return nil would be appreciated.