Two-way values for Blend with Blend.Bind(prop)

[OttoHatt]

Svelte is a frontend web library, with a feature I really like called Bindings. They allow you to define information as flowing both ways on a component's property.

Usage would be [Blend.Bind(string)] = ValueObject<any>. It would simply be a shorthand for defining [prop] = valueBase and [Blend.OnChange(prop)] = valueBase.

-- Before:
local state = Blend.State("hi")
Blend.New "TextBox" {
	...
	Text = state;
	[Blend.OnChange "Text"] = state;
	...
}:Subscribe()

-- After:
-- Identical functionality.
-- [Blend.Bind(string)] = ValueObject<any>.
local state = Blend.State("hi")
Blend.New "TextBox" {
	...
	[Blend.Bind "Text"] = state;
	...
}:Subscribe()

In this example, both will function identically; setting the textbox contents to "hi" immediately, then updating the value of the state from a GetPropertyChangedSingnal("Text") as the user enters text. And when the value of state changes, the property will be set again.

-- We can modify state and get dynamic reactions, just like normal!
local txState = Blend.state("")

Blend.New "Frame" {
	[Blend.Children] = {
		Blend.New "TextBox" {
			[Blend.Bind "Text"] = txState,
		},
		Blend.New "TextLabel" {
			Text = txState,
		},
		Blend.New "TextButton" {
			Text = "Reset",
			[Blend.OnEvent("Activated")] = function()
				txState.Value = ""
			end,
		}
	}
}
:Subscribe()

This could even be used to deprecate ValueObject-like classes as event handlers (as it isn't a very intuitive API imo. It feels like hidden functionality, as with typical roblox :Connect you think it'd only take a Callback)

local sizeState = Blend.state(nil)

Blend.New "Frame" {
	-- Potentially confusing.
	-- Don't we connect function callbacks to a changed event?
	[Blend.OnChange("AbsoluteSize")] = sizeState;
	-- Better?
	-- But we must note that unlike .OnChange, this will immediately set the value to what's stored in the sizeState ValueObject.
	-- However I think that's fine, as it'll typically be initialised to nil, so it won't change from the default property.
	-- So I think for 99% of cases, .Bind will be a drop-in replacement and won't break any code.
	[Blend.Bind("AbsoluteSize")] = sizeState;
}:Subscribe()

[Quenty]

Bindings can explicitly be two way in this scenario. Right now the canonical way to do bindings is this:

local state = Instance.new("StringValue")
state.Text = "Hi"

Blend.New "TextBox" {
      Text = state;
      [Blend.OnChange("Text")] = state;
}

Note this nicely allows for multi-directional bindings in an explicit way.

BInd can be a nice way to shortcut this, at some confusion to the user on when to use one over the other.

I'll consider this.

[OttoHatt]

Yep, been thinking about this since posting the issue and, I think defining it explicitly as two statements is better.

The concern I had that this fixes is that [...] =ValueObject is not great for readability; you can't tell at a glance if it's a function or ValueObject. However, I now think this is fine as it's short to write - UI code doesn't need to get any messier!