Frontend пятиминутка

Всем привет!Сегодня последний день нашего небольшого марафона, посвященного доступности. Предлагаю завершить его еще одним достойным внимания докладом 🧃В контексте доступности я такие "подборки реальных кейсов" вообще очень люблю. В отличие от всяких копирующих друг друга текстов и видео под общим флагом "N ошибок начинающего разработчика", доклады и статьи, подобные этому, помогают рассмотреть вопрос доступности под разными углами.Это очень полезно — хотя бы попытаться взглянуть на мир глазами человека, для которого действительно важно, насколько хорошо мы понимаем, что делаем, ведь это гораздо сильнее отражается на его ежедневном опыте взаимодействия с нашими приложениями.Приятного просмотра 🧐Stay tuned!

Всем привет!В продолжение нашего с вами небольшого марафона, посвященного разработке доступных интерфейсов, предлагаю вам посмотреть интересный доклад, посвященный сбору ошибок доступности в режиме реального времени.Обсуждение в комментариях приветствуется 🙂Stay tuned!

Всем привет!Сегодня мне бы хотелось поделиться с вами культовым докладом, появления которого в открытом доступе я ждала очень-очень долго 🤩Встречайте: Сергей Соловьев — "От римских императоров до Temporal API: покоряем даты и время в JS"Все мы знаем, что даты и время — это огромная боль. В этом докладе много интересной исторической информации, которая дает нам полную картину того, почему все так, как оно есть. Ну и немного света в конце тоннеля, разумеется, а именно — разбор Temporal API. Глядишь, когда-нибудь мы доживем до его широкого применения)Приятного просмотра 🧐Stay tuned!

Всем привет!Сегодня разберем правильный ответ на вчерашний вопрос 🧃Для начала коротко вспомним, зачем нам вообще нужен forEach(). Это метод, который позволяет нам обойти заданный массив и совершить один и тот же набор операций над каждым элементом нашего массива по очереди, без возможности пропустить какой-то элемент или вовсе прервать обход. При этом forEach() избавляет нас от необходимости явно описывать цикл — мы просто передаем в него коллбэк с инструкциями и радуемся жизни. Он ничего не возвращает — только выполняет переданные инструкции.Важной для нашего сегодняшнего разбора особенностью forEach() является то, что он не ожидает асинхронных операций. Каждый await внутри forEach() создает промис, но forEach() не приостанавливает выполнение и сразу переходит к следующей итерации, поэтому все промисы выполнятся лишь после того, как сам forEach() завершит свою работу.Почему так? 😨forEach() — метод строго синхронный. Он просто вызывает функцию для каждого элемента массива и забывает о ней. Кроме того, он не собирает промисы из коллбэков и не предоставляет механизм ожидания.Учитывая это, даже если коллбэк будет асинхронным, это никак не повлияет на внешний forEach() — из-за своей синхронной природы он будет видеть коллбэк как обычную функцию и даже не заметит, что там есть эта ваша бесовская асинхронщина.Таким образом, в коде из вчерашнего примера сначала отработает console.log("Done!"), а лишь затем в порядке выполнения разрешаются промисы — и в консоль выводятся 1, 2 и 3.Если все-таки ну очень хочется скрестить обход массива и асинхронщину, можно рассмотреть, к примеру, один из следующих вариантов:1. Помедленнее (из-за последовательного выполнения операций), зато с гарантированным порядком выводаasync function processArray(array) { for (const item of array) { await new Promise(resolve => setTimeout(resolve, 100)); console.log(item); } console.log("Done!");}2. Побыстрее (благодаря параллельности выполнения), но порядок вывода будет "какой придется"async f

Всем привет!Сегодня разберем правильный ответ на вчерашний вопрос 🧃Откуда взялся банан? 🙁В JS переменные и выражения не имеют строгого типа (в отличие, например, от TypeScript или C++). Тип определяется автоматически во время выполнения кода, и одно и то же выражение может вести себя по-разному в зависимости от контекста. Иногда такое поведение может оказаться удобным, но чаще всего оно приводит к различным интересным последствиям разной степени фатальности — как в случае с нашим бананом.Давайте разберемся, как же так получилось.Начинается все вроде бы неплохо: 'b' + 'a'. Сложение двух строк — вполне себе валидный случай, так что + отрабатывает как конкатенация и склеивает оба операнда воедино — получаем 'ba'.Дальше интереснее — 'ba' + + 'a'.+ 'a' считывается JS-ом как унарный плюс. Принцип его работы таков: "попытайся превратить в число то, что стоит справа от тебя". Что он, собственно, и пытается сделать. Но не может — ведь 'a' не цифра, а буква!Таким образом, унарный плюс отдает нам NaN, и наше выражение принимает следующий вид: 'ba' + NaN.Теперь наш + снова ведет себя как конкатенация — поскольку одно из слагаемых является строкой. Но чтобы сложить две строки, нужно, чтобы и второе слагаемое тоже было строкой. Поэтому JS неявно преобразует NaN в строку 'NaN', вызывая для него NaN.toString().И вот мы уже складываем 'ba' + 'NaN' — и получаем 'baNaN' .Ну а дальше JS-у даже заморачиваться больше не надо)('baNaN' + 'a').toLowerCase() — вот и получилось 'banana' 🥳Этот пример — отличный повод уделить побольше времени системе типов JS и их преобразованиям. Ибо неисповедимы пути динамической типизации 🙂Stay tuned!

Всем привет!Сегодня разберем правильный ответ на вчерашний вопрос 🧃Для этого нам понадобится разобраться с двумя концепциями — hoisting и temporal dead zone.HoistingСлово "hoisting" можно перевести с английского как "поднятие" или "всплытие". И это будет история о том, как в JS работает объявление переменных.Давайте рассмотрим такой код:console.log(a); // undefined, а не ошибка! var a = 10;Здесь мы пытаемся обратиться к переменной a до того, как объявили ее, но ошибки почему-то не получаем.Почему?В момент выполнения этого кода сработал механизм "всплытия" — hoisting. Иными словами, JS, изучая наш код перед выполнением, обратил внимание, что нам потребуется для работы переменная а, и сам решил, где ее будет лучше объявить. Поэтому, когда срабатывает "всплытие", все объявления переменных "переезжают" вверх области видимости.Кроме того, сработал еще один фокус: если переменная объявлена при помощи ключевого слова var, то она "всплывает" со значением undefined, Поэтому фактически при выполнении наш код выглядит вот так:var a; // принимает значение undefined, т.к. не присвоено никакого другого значенияconsole.log(a);a = 10;При чем тут Temporal Dead Zone?Temporal Dead Zone (TDZ) — это состояние, в котором пребывают переменные, объявленные при помощи ключевых слов let и const до момента инициализации — то есть до тех пор, пока в нашем коде им не будет присвоено значение.Именно это состояние постигнет нашу переменную при выполнении следующего кода:console.log(b); // ReferenceError: Cannot access 'b' before initialization let b = 20; Когда мы пытаемся выполнить console.log(), JS уже в курсе, что нам потребуется переменная b для работы. Однако наша переменная объявлена при помощи ключевого слова let — поэтому она всплывает, но попадает в Temporal Dead Zone, потому что JS запрещает нам пользоваться ею до инициализации.Такому же закону подчиняются и переменные, объявленные при помощи ключевого слова const.Это поведение очень легко увидеть в режиме отладки. Если прогнать чер