Question: did you benchmark it?

[AlexGalays]

Hello! the idea behind react-tracked seems interesting.

You claim the performances are better but did you actually verify that? Aren't you creating a completely new proxy on each update?

Cheers

[dai-shi]

Hi,

The latest benchmark result at the moment is here: #1 (comment)
Compare react-tracked-useSelector and react-tracked-useTrackedState too see the tracking overhead.

creating a completely new proxy on each update

Yeah, that's the point, because we don't know when render process ends.
It's optimized with per-hook cache, so it won't create a new proxy for the same object.
This means immutable state update is important.
Related discussion: #7 (comment)

[AlexGalays]

Ok thanks, guess we can close this then :)

It seems useSelector is not that much faster and is quite a bit less ergonomic, what do you think?

[dai-shi]

Theoretically, useSelector is faster than useTrackedState if a selector is properly implemented.

The code in js-framework-benchmark is very simple and we don't see a big difference. You can see useSelector is faster in "select row."

Here's another benchmark for reactive-react-redux, as a reference.
dai-shi/reactive-react-redux#32 (comment)
Those benchmarks are with extreme usage, and especially for "stockticker" useTrackedState is slower.

In summary, useTrackedState is as fast as useSelector for most cases. In some cases, useTrackedState is slower. I don't have a benchmark, but if a developer wrote a selector improperly (which is likely), useSelector would be much slower.

[dai-shi]

Forgot to respond this part:

less ergonomic

Totally. It should be much more intuitive for most of the cases.
Some edge cases exist, though, as written in the limitations section. It may occur if you deal with object ref equality.