eager option for signals

[WebReflection]

I am fully aware the philosophy of signals should be "once ref changes, effect out there" but there are cases that drive signal reactivity, without ever being involved in such reactivity ... let me expand on that:

const rawData = [];
const data = signal(rawData);

// this drives changes but it doesn't want/need to create a new
// array holding potentially 1000 things in `data`
document.querySelector('.my-thing').onclick = (event) => {
  const { dataset } = event.currentTarget;
  rawData[+dataset.id] = dataset.value;
  data(rawData);
};

// here the effect that should react on '.my-thing' click
effect(() => {
  const target = document.querySelector('.my-target');
  for (const value in data()) {
    // do something in there
  }
});

So, the target effects on data changes but data changes shouldn't be sliced or copy because other parts in the stack might be involved and have reference to that very same data for other reasons ... accordingly, could we add an eager = false extra option (or even an option property for future sake such as signal(value, { eager: true })) so that update for both computed and signals could return true whenever it's explicitly intentional to trigger updates on mutable data changes ???

Performance are an issue but also reference fan-out when in some scenario one doesn't want-need to react to any data change but would like to drive reactivity through such shared data, like it is for my .my-thing click example.

That means that at least updateSignal https://github.com/stackblitz/alien-signals/blob/master/src/index.ts#L200C10-L203 should do instead:

function updateSignal(s: Signal, value: any): boolean {
	const { previousValue } = s;
	s.flags = 1 satisfies ReactiveFlags.Mutable;
	s.previousValue = value;
	return s.eager || (previousValue !== value);
}

That also aligns with the current logic because you do (while returning) s.previousValue !== (s.previousValue = value) which invokes explicitly a set operation indeed, but nobody can decide how that set operation could react.

Thanks for considering or expanding around these choices, my proposal feels easy to implement and it'd improve a lot use cases around signals, yet I am sure you have opinions or reasons for not wanting such proposal in here and I'm happy to hear or learn about it 👋

[WebReflection]

btw, I've just implemented this as greedy instead of eager as that term/option felt like better suited for the task, also it involves only signals, not computed values ... it works well in my Preact variant here https://github.com/WebReflection/alien-signals

[nickchomey]

FYI, you might find something useful in this alien-inspired signals implementation. I know they did a ton of research and experimentation and ended up with this.
https://github.com/starfederation/datastar/blob/develop/library%2Fsrc%2Fengine%2Fengine.ts

[medz]

#75 Maybe you need this. I had a similar requirement a while ago. I wanted to trigger updates to both Array and Map items without using a Proxy. Later, with Johnson's guidance, I completely solved the problem.

[WebReflection]

so it's trivial on my side, so maybe there's no need to add this in alien-signals core, yet it'd be handy to have a flag in there that can "compose" with the rest of the flags.

const greedy = value => {
  const $ = signal([value]);
  return function (value) {
    return arguments.length ? $([value]) : $()[0];
  }
};