proposal-record-tuple VS react-tracked

Records and tuples are unlikely to ever ship, or at least are extremely unlikely to ship with the semantics around equality people want. My understanding is that browser vendors already have pretty strong opposition to introducing new primitives at this point. Reading this thread[1] will give some explanation as to the hiccups with how equality would behave. It sucks, because while I wouldn't have expected BigInt to have gotten much adoption in the first place, I constantly run into cases where I'd want records or tuples.

[1] https://github.com/tc39/proposal-record-tuple/issues/387

The next big step is dependent on JS language/runtime features. Specifically the Record-Tuple proposal (https://github.com/tc39/proposal-record-tuple)

TL;DR: It's a way to designate data as being immutable.

JS doesn't currently have a good way to do this, so everything built for it tries to assume that data hasn't changed since it was last set. This leads to headaches for developers and wasted cycles for runtimes.

When JS has a proper way to make data immutable, it makes it easier for libraries/frameworks to make guarantees about the underlying data and makes it possible for runtimes to better optimize code.

relevant issue, which is at the crux of this problem: https://github.com/tc39/proposal-record-tuple/issues/387

There are still so many basic things that aren't in the JS stdlib, though. A good example is Map - if you need to use a tuple of two values as a key, you're SOL because there's no way to customize key comparisons. Hopefully we'll get https://tc39.es/proposal-record-tuple/ eventually, but meanwhile languages ranging from C++ to Java to Python have had some sensible way to do this for over 20 years now.

If you’re reaching for structuredClone, what you really want is native immutable Record and Tuple syntax, and the companion “deep path properties” syntax which allows for efficient and ergonomic immutable updates:

- https://github.com/tc39/proposal-record-tuple

It will be called "record" in JavaScript which will swing the popularity back the other way I guess (currently a language proposal)

I suspect considering the strong desire to maintain consistency with JavaScript, we will eventually see something that when the Record proposal passes through tc39

I hope the Record and Tuple proposal makes it through

Automatic render optimization is to do this automatically. Is this possible? It's possible with utilizing proxies. Proxies allow us to detect state property access. I have been working on this for years, and react-tracked is one of the resulting projects that use this technique. We have an internal library called proxy-compare.

While in a smaller application, excessive re-rendering may be unnoticeable or have no negative impact, as your application grows, each re-render may cause delays or lags in your UI. In this tutorial, we’ll use React Tracked, a library for state usage tracking, to optimize our application’s performance by preventing unnecessary re-renders.

The best, and perhaps only approach I have found so far is react-tracked. It does some internal tracking with proxies that I don't quite understand, but it actually works as advertised with a very minimal API.