Proposal: consider using 2-way bindable structures. #619

You could easily create a directive to have bidirectional data binding, i.e. <input use:bind('value', user.firstName) />. Everything else is just semantic sugar.

I did very intentionally design Solid in a way that would make 2-way binding require specific consideration. As @atk suggested for the input case it would be pretty easy to setup a custom directive for this. Like if it was just for inputs you could probably do this:

function model(el, accessor) {
  const [s, set] = accessor();
  el.addEventListener("input", (e) => set(e.currentTarget.value));
  createRenderEffect(() => el.value = s()); 
}

const [firstName, setFirstName] = createSignal("");
<input use:model={[firstName, setFirstName]} />

But this could be tailored even more to your case where you have wrappers.

I think that this request is 2 part.

1. Have a signal that combines getter/setter functions like KnockoutJS.
2. Have a syntax that automatically does the 2-way binding.

The first is easy to do for anyone, and I don't intend to change the default signature. As I said it is very much intentional. There are consequences to this beyond my desire for unidirectional flow (which I could and have written full articles about). Mostly that our accessors know they are just functions. Any function. I don't want isSignal to be a thing ever. There are all the weird mishaps with people accidentally providing Signals to argumentless functions that end up having or eventually having arguments.

Beyond DX issues there are performance considerations when people start being pushed to provide wrapped values that are special. Ultimately adding another official form is confusing.

From that perspective similarly having sugar for the JSX bindings seems out of place. Of course, a custom directive addresses this reasonably.

I'm pretty happy that if someone like yourself wanted to take things this way they could. But I don't want to muddle the patterns/best practices we're building here. If a good pattern emerges from the community that could be a consideration, but I don't think the framework can support being multi-paradigm itself right now.

thanks for detailed feedback, will certainly look to the use directive approach.

Since this is sort of open ended and proposal of sorts I think we should move it to discussions until there is an actionable item for it.

FYI, Qwik just gave native support for input using directive: QwikDev/qwik#3433

I quite like the idea