Open timonkrebs opened 1 year ago
The perf optimization looks reasonable, I'm working on updating my benchmarking suite to fix a few bugs but I'd be happy to merge if we see improvement there.
As for signalOperators, that is an interesting problem. I think having certain operators like that is definitely useful, but conceptually rxjs time based operators don't always fit super well with signals. However, so long as you can keep the boundary between signals and events clear and simple, I think those operators should work great
Really looking forward to see if it has a significant impact. It depends on the usage.
What are the issues you see with the time based operators?
One thing that could be awkward that i see would be SSR. If it should be serialized but not yet stable. But i think this can be solved.
I am in the process of implementing a lib that is inspired by reactively. But it is implemented in a multi threaded language. Therefor I have to make sure it is not a problem when multiple threads are getting values at the same time as they set values.
I noticed, that I could just put locks around the get code and it should work fine. But now I have to do more work to ensure this does not impact the pref of it all more than necessary. That is why I found this perf optimization. I think there could be cases for reactively that benefit from this.
One idea I would like to implement is an idea from @mfp22 for signal operators (https://stackblitz.com/edit/stackblitz-starters-tvvtbb?file=src%2Fmain.ts) that are inspired by rxjs. I think this could be something that is also interesting for solidjs. But i am still starting.
What do you think?