Two way computed signals

[lucacasonato]

It'd be great if Preact supported two way computed signals. They are particularly useful when you "derive" a signal from a different signal. They are essentially a computed signal, with a setter function that would be called when the user assigns to the computed signal's value.

This is particularly useful when you have an object and you want to turn a property of that object into it's own signal that you can pass to a child component (while allowing that child component to modify the value).

An example:

export function Page() {
  const project = useSignal({ name: "abc" });
  const name = useComputed(
    () => project.value.name,
    (newName) => project.value = { ...project.value, newName },
  );

  return (
    <div>
      <h1>Project page</h1>
      <label>
        Project name:
        <Input bind:value={name} />
      </label>
    </div>
  );
}

export function Input(props: { "bind:value": Signal<string> }) {
  return <input value={props["bind:value"]} onInput={(e) => props["bind:value"] = e.currentTarget.value} />
}

The minimal API surface would be to accept a second callback in useComputed that acts as a setter function. A slightly nicer API would be to have useComputed take an object, with a get and set method on them (this would likely result in better code formatting with most formatters as compared to two unnamed callback functions.

[XantreDev]

It can be implemented in the user land quite easily
Why should it be a part of the library?

If I have free time I attach the gist

[JoviDeCroock]

I can see the value in a feature like this, we're basically creating an observed value and upon change we invoke a side-effect. To me this doesn't fit in scope of the computed concept though, this feature also seems very tailored towards the philosophy of making top-level values reactive rather than leaves.

One concern I have with this approach to observing value changes is that we are creating a level of indirection for value changes. We observe the root-signal, when the boxed value of the root-signal changes we check a property of the boxed value and when that one has changed we change a property of the boxed value. This could really be a cause of confusion imho.

A point of confusion for me is the why behind this, in your example we are updating project.value.name. This happens when the identity of project.value changes and by some chance has a different name value.

We could bridge this by making project.name a signal. This could maybe not fit in certain use cases, I am having issues seeing them at this point in time so please do tell.

I can see a case for this being a supplementary export outside of the core library named i.e. reactive, my main reasoning for this being outside of the core library is that this is a pretty advanced use case and tailored towards a specific philosophy.

As alluded to in the above this could probably exist in userland in some shape with the exception that previous value tracking for the comparison could be a bit troublesome.

[XantreDev]

I've started to play with the concept and realized that I've already implement it 2 years ago
You can check it here

https://github.com/XantreDev/preact-signals/blob/b3464bfee6a714e8c99812bf2313b02e6cc8ae4e/packages/utils/src/lib/%24.ts#L169-L170

[ghchaosfae]

we needed this, and so we committed code crimes to get it.

⚠️ This is brittle! ⚠️ (It relies on internal details, and while they aren't super likely to change, it could just break on a signals patch update technically)

import { computed, Signal } from "@preact/signals";

type ComputedParams<T> = Parameters<typeof computed<T>>;

const computedInstance = computed(() => {});

// eslint-disable-next-line @typescript-eslint/unbound-method, @typescript-eslint/no-non-null-assertion
const signalValueGetter: unknown = Object.getOwnPropertyDescriptor(
	Object.getPrototypeOf(computedInstance),
	"value",
)!.get;

export function bidirectionalComputed<T>(
	fn: ComputedParams<T>[0],
	writer: (value: T) => void,
	options?: ComputedParams<T>[1],
): Signal<T> {
	const computed_S = computed(fn, options) as Signal<T>;
	Object.defineProperty(computed_S, "value", {
		get(this: Signal<T>): T {
			return (signalValueGetter as () => T).call(this);
		},
		set(value: T) {
			writer(value);
		},
	});
	return computed_S;
}

[aleclarson]

@JoviDeCroock I think there’s a core use case here beyond making object leaves reactive: writable projections over canonical state.

For example, a parent may intentionally store state as a discriminant:

const current = signal<"project" | "model" | null>(null)

A generic child primitive may still reasonably want a writable Signal<boolean>:

const modelOpen = writableComputed({
  get: () => current.value === "model",
  set: open => {
    current.value = open ? "model" : null
  },
})

This keeps current as the single source of truth and preserves invariants like “only one picker can be open,” while still letting child components read and write a normal signal. Modeling this with independent leaf signals would allow impossible states. Modeling it with value + onChange APIs works, but it weakens the main Signals ergonomics: components can no longer just accept and mutate a Signal<T>.

So I agree this probably should not be called computed, because assignment is semantically meaningful and delegated to user logic. But I do think a small core primitive for writable computed projections makes sense. It would be cached/subscribed like computed(get), remain a real Signal<T>, and add only one explicit write path:

const projected = writableComputed({ get, set })

That also avoids pushing users toward ad hoc wrapper objects that look signal-like but are not actually signals, or toward duplicating derived state just to satisfy child component APIs. The feature is advanced, but the invariant it supports is fundamental: expose a focused writable view without giving up the canonical state shape.