divdavem
divdavem
> I believe that mutation during computation should be completely prohibited. What is in the computed should be a pure function. @szagi3891 Thank you for expressing your opinion. It is...
@NullVoxPopuli Thank you for your answer! > @divdavem have you tried using untrack within the computed? Do you mean around `s.get()`? But I would still like the computed to be...
> how would that be implemented algorithmically? @NullVoxPopuli I have opened https://github.com/proposal-signals/signal-polyfill/pull/19 to show how this could be implemented.
@EisenbergEffect Thank you for your answer. To answer your question, I have written below a very simple implementation of signals that relies (only) on the above `SignalInterop` namespace. Note that...
@EisenbergEffect Thank you for your answer. I have opened [this PR on Angular](https://github.com/angular/angular/pull/60132) with an implementation of my proposal for Angular signals. I would be happy indeed to collect feedback...
Cf also #197 In [tansu](https://github.com/AmadeusITGroup/tansu), we store the last value and version number on the edges, and this works well. We only call equal if the version number changed and...
What do you mean by your `toComparable` callback? Here are some advantages of storing values on the edges (rather than having a cache on the node): - the whole system...
> A downside of storing the values on the edges is that you have to remember to opt in to the `toComparable` to prevent leaking memory where it matters, whereas...
> The "reference to the consumer" is the "edge" of the dependency graph, so you need to store that one way or another for the signal to be reactive, and...
Note that the signal being watched while not up-to-date, also leads to the fact that a change to some of the no longer used signals triggers the notification: ```ts const...