Proposal: consider using 2-way bindable structures.

[vaukalak]

I know that, this might sound as a paradigm change, however inspired by this library, I've created a poc library for 2-way bindable structures, that might be considered for solid:
This would change api in following way:

const User = () => {
  const user = useState({ firstName: "Adam", lastName: "Smith" });
  return (
    <>
      <input value={user.firstName()} onChange={(e) => user.firstName(e.target.value)} />
      <input value={user.lastName()} onChange={(e) => user.lastName(e.target.value)} />
      <SomeUserPanel user={user()} setUser={value => user(value)} />
    </>
  );
  // or 2 way binding approach
  return (
    <>
      <input $value={user.firstName} />
      <input $value={user.lastName} />
      <SomeUserPanel $user={user} />
    </>
  );
};

[atk]

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.

[ryansolid]

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.

[vaukalak]

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

[ryansolid]

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.

[emindeniz99]

I had loved the knockout js's observable style, I have missed it when writing react js.
I think It can be helpful.

import { render } from "solid-js/web";
import { createSignal } from "solid-js";

// helper function
function createSignalWithKnockoutObservableStyle(init) {
  const [signal, setSignal] = createSignal(init);
  return (...args) => {
    if (args.length > 0) {
      return setSignal(...args);
    } else {
      return signal();
    }
  };
}

function Counter() {
  const count = createSignalWithKnockoutObservableStyle(3);
  const increment = () => count(count() + 1);

  return (
    <button type="button" onClick={increment}>
      {count()}
    </button>
  );
}

render(() => <Counter />, document.getElementById("app"));

https://codesandbox.io/s/solid-js-createsignalwithknockoutobservablestyle-xf88h4?file=/src/main.tsx

[atk]

There is a package called solid-use, which contains this: https://github.com/LXSMNSYC/solid-use/blob/main/packages/solid-use/src/atom.ts

[emindeniz99]

There is a package called solid-use, which contains this: https://github.com/LXSMNSYC/solid-use/blob/main/packages/solid-use/src/atom.ts

Thank you

[GermanJablo]

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

I quite like the idea