proposal-class-fields VS dedent

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

and so `dedent` would not strip any indentation. That is, `dedent` is meant to identify the maximal common leading indentation in the template as written by the developer, which should not depend on the values of the interpolands.

A stale GitHub issue on the dmnd/dedent repo has a real-world example where this matters and led to a subtle bug: https://github.com/dmnd/dedent/issues/22

There is also some other interesting use cases.