proposal-record-tuple VS react-18

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

Record and tuple is at stage 2

Can't wait until we get records and tuples and you won't have to resort to shenanigans like this just to check if data is equal to other data

I hope Records & Tuples[0] land before this does. It would have meaningful and far reaching positive effects for the language, without much controversy. Like most of these things, it takes about 5-7 years for it to permeate through enough of the engines to be meaningfully useful in the day to day of web developers (node / deno typically 12-18 months tops). It would drastically speed up existing code once wide adoption is gained though.

I don't think the Pipe Operator would be as useful in comparison

[0]: https://github.com/tc39/proposal-record-tuple

You might be interested in the Stage 2 Tuples and Records proposal. It's one of the proposals I'm most excited about, but there will be interesting discussions on how TypeScript will integrate those into their type system.

Image Source: https://github.com/reactwg/react-18/discussions/37

The React working group is officially advising against using runtime CSS-in-JS.

Interesting about the feedback, thanks for the clarification. In general what I'm thinking of is PR's like this one in React where you see lots of back and forth from the community to get things right. Looking at Vue trying to transition from 2 to 3 and even Python from 2 to 3, it seems like it's not easy. I might be making an unfair comparison here though, I don't know much about those transitions except from what I've heard.

Redux with sagas is a great hint to a solution that is only a small tweak of what you currently do. You need middlewares (that's what makes sagas possible)! Contrary to what some may suggest, you actually don't need to use external state management to get middlewares, as you can integrate an enhancer to useReducer itself. And you should be aware that moving off-react state management "updates triggered by external stores are always synchronous" meaning you're losing startTransition powers.

Anything that uses css-in-js (styled-components / emotion) won't currently work properly: https://beta.nextjs.org/docs/styling/css-in-js the problem isn't related to emotions SSR strategy as that relates to client components being statically pre-rendered. The problem actually relates to the implementation of these solutions as they do not work very well with the new concurrent rendering patterns of react 18 and they haven't completed the upgrade process explained here: https://github.com/reactwg/react-18/discussions/110 this will be a pretty large fundamental change to emotion, so may take a fair while to fully support it, especially given that next's app folder is still a beta feature :)

In React 18 and onwards runtime css-in-js libs will have significant performance issues for concurrent rendering, recomputing inline styles repeatedly and redundantly; https://github.com/reactwg/react-18/discussions/110 . Facebook have no real interest into fixing this I believe (I assume it would be hard with unwanted trade-offs). Facebook themselves use a buildtime css-in-js lib(not open source).

I switched back to SASS modules in NextJS due to the issue with runtime CSS-in-JS in NextJS18 and onwards: https://github.com/reactwg/react-18/discussions/110

1. Frequently inserting CSS rules forces the browser to do a lot of extra work. Sebastian Markbåge, member of the React core team and the original designer of React Hooks, wrote an extremely informative discussion in the React 18 working group about how CSS-in-JS libraries would need to change to work with React 18, and about the future of runtime CSS-in-JS in general. In particular, he says: