InstanceProperty(instance, propertyName) state-like helper about fusion

[Dionysusnu]

This is definitely something we can consider, though perhaps with a more concise name.

It usually ends up being wrapped in a heartbeat updating state.

There shouldn't be any reason to do this - instead of connecting to Heartbeat, you could also connect to a property change event in a comparable number of characters.

Unfortunately not all events fire with GetPropertyChangedSignal. Looking at you, BasePart.Velocity.
Even so, that's verbose and a lot of code repetition.

local partColor = State(myPart.Color)
myPart:GetPropertyChangedSignal("Color"):Connect(function()
  partColor:set(myPart.Color)
end)

local partTransparency = State(myPart.Transparency)
myPart:GetPropertyChangedSignal("Transparency"):Connect(function()
  partTransparency:set(myPart.Transparency)
end)

-- now we can use partColor and partTransparency

as opposed to

local partColor = InstanceProperty(myPart, "Color")
local partTransparency = InstanceProperty(myPart, "Transparency")

-- now we can use partColor and partTransparency

[dphfox]

This is definitely something we can consider, though perhaps with a more concise name.

It usually ends up being wrapped in a heartbeat updating state.

There shouldn't be any reason to do this - instead of connecting to Heartbeat, you could also connect to a property change event in a comparable number of characters.

[dphfox]

After some more thinking, I think that this would be better served by hydration (#34) and out props (#88), so I'm going to close this issue for now.

[Dionysusnu]

Worth noting that this is now supported for static instances with #121:

local instanceTransparency = Value(instance.Transparency)
Hydrate(instance)({
  [Out("Transparency")] = instanceTransparency,
})

-- later
local foo = Computed(function()
  return 1 - instanceTransparency:get()
end)

And for dynamic instance references, is in consideration at #134