immutable-js VS proposal-record-tuple

immutable for JavaScript.

Check out Object.freeze. There's also Immutable.js for working with immutable data.

Use immutability to manage state updates When updating state in your React application, it's important to ensure that you are not mutating the original state object. Instead, you should create a new copy of the state object with the updated values. Immutability makes it easier to manage state updates and ensures that the updates are performed in a predictable and safe manner. Libraries like Immutable.js provide a set of functions that simplify working with immutable data in React applications.

Enter Immutable.js, a library for creating and updating immutable state in JavaScript. With usual mutable JavaScript objects you might write something like:

The Immutable.js README has a much more complete description of immutability and why you might want to use the library. Also worth mentioning that Immer is an alternative which is a bit easier to get started with.

Examples: immutable-js Immer

I can't speak to C# and Java, but the suggestion in this post: ImmutableJS already uses Persistent data structures. (It's the second sentence of their introduction)

feed.feedManager.state.activities is an immutable Map (created with Immutabe.js), so you get the activity object using getIn and toJS methods.

You could create explicitly immutable references and state by using a tool like Immer.js or Immutable.js and do something like your example using their API.

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.