proposal-class-fields VS proposal-record-tuple

Private methods: Pretty simple to explain, private methods and fields straight up do not work with ES6 proxies, its a known issue https://github.com/tc39/proposal-class-fields/issues/106

The #x syntax is ugly and many people don't like it. But if you understand how JavaScript works, you'll see that private x is not possible. Some comments on the proposal suggested private #x and there were plenty of other suggestions as well, it may be interesting to read through those discussions.

> - # private... not sure why they didn't just use the "private" keyword, but I don't care. I almost always use TypeScript anyways

One of the reasons was to allow private and public fields of the same name, so that subclasses are free to add own public fields without accidentally discovering private fields. There were many more considerations that went into the design: https://github.com/tc39/proposal-class-fields/blob/main/PRIV....

There was a heated debate about this and the choice of the # sigil back in 2015 at the time private fields were being designed: https://github.com/tc39/proposal-private-fields/issues/14.

Private class fieldlari va nihoyat classlarda access modifierlarni (private,static) qo'llash imkonini beruvchi sintaksis.

class App extends React.Component { constructor(props) { super(props); this.state = { counter: 0 }; }} but due to Babel's class-field support, I don't use it anymore

I am using ReactJS with Babel and Webpack and using ES6 as well as the proposed class fields for arrow functions. I understand that arrow functions make things more efficient by not recreating the functions each render similar to how binding in the constructor works. However, I am not 100% sure if I am using them correctly. The following is a simplified section of my code in three different files.

Working with constructor and calling super() before we can set state. Although this has been solved with the introduction of class fields in JavaScript, Hooks still provide a simpler 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

I mean, I'd love some real immutable/persistent data structures in JS by default, or even some Immer-like syntax sugar. Something like the record/tuple proposal would be awesome.

This will become very useful once Records and Tuples are a thing, because it allows you to store object references in a record/tuple (which by definition can only contain primitives).

Record and tuple is at stage 2

Also, js has an ongoing immutable value data types proposal.