Комментарии 25
Интересно, что быстрее replace() с регуляркой или replaceAll()
Мда, скоро код на JS будет выглядеть как обфусцированный)
Особенно смущает решение использовать # в качестве маркера приватных методов. Лично я пишу не только на JS и для меня это все ещё остаётся маркером комментариев
Подсветка синтаксиса решит не всю, но большую часть вашей боли. А так - было бы на клавиатуре побольше разных других знаков - возможно был бы он, но, по сути, это последний такой не используемый. Можно конечно ещё дописать private, это валидно, хоть и многословно, но может сломать TypeScript - приватные методы оттуда не эквивалентны тем что добавили в JS т.к. у добавленных приватность на уровне объекта самого, а не доступа до поля, разное поведение. Ну и в целом, возможно, плохая идея многословности добавлять именно в сам JS. Но всё это так, сугубо мои личные мысли.
Но на клавиатуре уже есть символ, который помогает пометить приватные методы в языках, которые их не поддерживают и этот символ "_". Почему бы просто не использовать его?
Также можно было бы добавить ключевое слово "private" и вообще не использовать никакие странные символы.
Просто приватные поля, это прям приватные, единственное место где к ним можно обращаться, это в рамках класса. Символ нужен чтобы интерпретатор смог понять, что идет обращение к приватному полю. При этом обращение через obj['#private'] остается валидным, и не является обращением к приватному полю, что позволяет сохранить обратную совместимость.
Если использовать _, то тогда мы сломаем с ходу огромное количество кода т.к. это валидное имя сейчас и в легаси много кто вызывает приватные методы, помеченные так, хотя как бы не правильно, но раз можно физически - то делают если очень надо. Будет не очень весело если апдейт языка половину интернета сломает, думаю вы со мной согласитесь.
Да и не в легаси :)
Как минимум, для тестов иногда полезно. Всегда проще напрямую вызвать в тесте obj._private() с @ts-ignore чем писать какие-то обертки
Непонятно, чем отличается Promise.any от Promise.race, лучше бы сравнили с ним, чем с Promise.all
set #generateUniqueStringByCustomLength(length = 24) {
this.#generateUniqueStringByCustomLength = length;
Выглядит ужасно, когда вместо метода делают сеттер, который тут совсем ни к чему.
Меня ещё сеттеры начинающиеся с set и геттеры с get покоробили. Они в принципе предполагают отсутствие любого глагола в имени. Надо на собеседованиях А4 страничку подобного шлака подавать и маркер, точно полезнее всякого литкода будет. А лучше ноут с кодом и потом мержреквест глянуть через полчаса )
Ещё чуть-чуть, кажется, и нативные типы с дженериками подвезут. Во заживём!
Добавили относительно бесполезные разделители разрядов чисел, при этом на реально нужные числа фиксированных размерностей даже предложения вроде нет. Если JS начинает позиционировать себя как язык для полноценных приложений (PWA), то часто требуется, например, unsigned математика, или деление с отбрасыванием остатка . В нормальных языках это решается путем объявления числа как unsigned и присваивание результата деления в int-переменную. В JS-же приходится писать костыли. При этом, т.к. все числа в js, по сути float64 - то на сложных вычислениях вообще получается ужас, как по костылям, так и по производительности. В некоторых частях кода, я наблюдал, как программисты делали примерно такой код:
let uint8 = new Uint8Array([originalNumberValue]);
Т.е. для создания и работы с одним uint8 числом, программистам приходится создавать TypedArray! Ну, либо, мучаться с битовыми масками и Math-функциями.
что странно - у меня в примере с запуском промисов первый срабатывает сначала. ЧЯДНТ?
Пофиг, всё равно TS используем =)
Спасибо, за интересную за статью!
А можно было просто добавить TypeScript в JS не все было бы хорошо.
Ещё интересен WeakRef (странная дичь, конешн), но блин
Стандарт ES: вот вам разделители, вот вам приватные свойства и методы, даже промисы апнули!
Двойное сравнение (a < b < c): ну да, ну да, пошли мы нахрен
5 возможностей JavaScript ES12, которыми стоит воспользоваться уже сегодня