proposal-class-fields VS notes

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

Has anything changed recently? The proposal has been in stage 3 since November 2022 [1]

[1] https://github.com/tc39/notes/blob/HEAD/meetings/2022-11/nov...

If you're curious about the naming scheme (it now goes 0 -> 1 -> 2 -> 2.7 -> 3 -> 4), then you can read the discussion surrounding the name from the last meeting notes [1].

Also, for a quicker digest, Rob Palmer (from the committee) tweeted about it [2]

[1] https://github.com/tc39/notes/blob/main/meetings/2023-11/nov...

Dialog for this update is at https://github.com/tc39/notes/blob/main/meetings/2023-03/mar...

What I would like is a "use: 'typechecked'" at the top of the file indicating that the code has already been checked. This would be accompanied by a new proprosal that defines a standard for what is considered checked (for example checking nullablity in the types) and would allow for browsers to make some optimizations. This could also perhaps reduce the amount of necessary runtime checks such that it would be possible to make it a fully sound typesystem with most of the checks done beforehand.

All the meeting notes are recorded here: https://github.com/tc39/notes/tree/main/meetings. You’ll have to do a bit of spelunking in the corresponding agendas and proposal repo to narrow down the exact meetings you’re interested in.

Here's a list of delegates for TC39, but it doesn't list people by their ECMA member organization.

This is a good question. I'm not sure I saw the notes of the meeting when this happened, but all the notes are public here: https://github.com/tc39/notes/tree/master/meetings

TC-39 is a group of people who are responsible for the standards. They have meetings every two months with member-appointed delegates and invited experts. You can check the minutes of those meetings here GitHub repository