Рубрика «возможности джаваскрипта, о которых лучше бы и не знать»

Сегодня обнаружил, что в джаваскрипте есть аналог goto, и это не throw/catch. Любой цикл или блок можно подписать, а затем сослаться на него в инструкциях break/continue. Внутри блоков разрешён только break:

foo: {
  console.log('ух');
  bar: {
    console.log('сейчас как залогируется');
    break bar;
    console.log('чёрта с два!');
  }
  console.log('ну же...');
  break foo;
  console.log('ну вот опять :–(');
}

// -> ух
// -> сейчас как залогируется
// -> ну же...

А в циклах можно ещё и continue:

outerLoop:
for (var i = 0; i < 5; i++) {
  innerLoop:
  for (var ii = 0; ii < 3; ii++){
    if (ii === 2) {
    continue outerLoop;
  } else if (i === 2) {
    break outerLoop;
  }

  console.log(`${i}${ii}`);
  }
}

// -> 00
// -> 01
// -> 10
// -> 11

Пользуйтесь на здоровье!

Потихоньку начинаю выкладывать рекомендации прочитанных книг, первая — «Грокаем алгоритмы»: http://andrew-r.ru/notes/?go=all/grokaem-algoritmy/

Пока не очень понимаю, каким должен быть этот формат. Напишите, чего не хватает или хотелось бы видеть в рекомендациях (конспекты, пересказы интересных мест, цитаты, etc): @andrew_r

Рассказываю, насколько мы близки к ванильному CSS без препроцессорного сахара — http://andrew-r.ru/notes/?go=all/preprocessors-vs-vanilla-css/

Рецензия на «Микрорешения» и конспект основных идей — http://andrew-r.ru/notes/?go=all/microresolutions/

TL; DR, если лень переходить по ссылке: решения вроде «стать более аккуратным» не работают. Вместо них принимайте конкретные, небольшие решения, которые легко осуществить и от которых сразу же есть профит — например, «заправлять постель утром». Привяжите эти решения к каким-либо событиям (сигналам), чтобы сформировать привычку. Фокусируйтесь не больше, чем на 1–2 микрорешениях, пока не выработаете привычку.

В SPA сломано много вещей, которые нормально работают в обычных сайтах. Одна из таких вещей — переходы между страницами. Используете динамический роутинг? Оберните содержимое страниц в элемент с tabindex="-1", role="region" и aria-label="Содержимое текущей страницы", а при переходах между страницами устанавливайте фокус на эту обёртку. Эта базовая техника сделает ваше приложение немного доступнее для тех, кто пользуется кнопкой tab или экранными читалками.

Реализация такой обёртки на Реакте

Использование обёртки с Реакт-Роутером (v3)

Ваня Акулов (@iamakulov_channel) справедливо спрашивает, зачем нужна эта обёртка — я не объяснил, в чём проблема.

Представьте, что в футере вашего SPA есть ссылка на страницу «о проекте». При клике по этой ссылке совершается динамический переход на нужную страницу, но даже после перехода фокус так и остаётся на ссылке. Из-за этого пользователи экранных читалок даже не узнают, что страница поменялась — для них это воспринимается так, будто никакого перехода и не было. Поэтому нужно после динамических переходов переносить фокус на контейнер страницы — тогда экранная читалка после клика по ссылке не будет молчать, а озвучит что-то вроде «Содержимое страницы, 5 элементов». Ну и если вы после динамического перехода нажмёте tab, фокус перейдёт на первый интерактивный элемент внутри страницы, а не на то, что располагалось после кликнутой ссылки.

Определяем видимость элемента с IntersectionObserver

IntersectionObserver это новый браузерный API, позволяющий асинхронно следить за степенью пересечения элемента с вьюпортом или другим элементом. С его помощью можно определить, виден ли элемент на экране, если виден, то насколько (целиком или частично), а также когда именно он оказался виден. Пример того, где это может потребоваться — модуль для ленивой загрузки картинок.

Недавно на работе была задача залогировать событие просмотра блока на сайте. Я как представил, что нужно подписываться на событие скролла и вручную считать, входит ли элемент целиком во вьюпорт... А затем вспомнил про IntersectionObserver, прочитал документацию и обрадовался, потому что с ним задача решается гораздо проще и красивее:

const observer = new IntersectionObserver(handleIntersection, {
    root: null, // отслеживаем пересечение с вьюпортом, а не с элементом, поэтому null
    threshold: 1 // порог видимости, при котором сработает обзёрвер; 1 означает полную видимость, 0.5 означало бы 50% видимости
});

observer.observe(document.getElementById('target'));

function handleIntersection(entries) {
    // Обзёрвер срабатывает в том числе когда элемент скрывается из вьюпорта, поэтому нужна дополнительная проверка
    if (entries[0].intersectionRatio === 1) {
        logBlockView();
    }
}

IntersectionObserver поддерживается в последних версиях Chrome, Edge и Firefox, для остальных браузеров есть полифил (6.6 КБ в минифицированном виде). Подробнее об IntersectionObserver на MDN.

У Эстонии есть собственная дизайн-система — https://brand.estonia.ee/

А ребята из http://gov.design теперь пилят единый навигатор по государственным сайтам и услугам — https://gov.gosuslugi.ru/

На собеседованиях иногда просят назвать способы отправки запроса на сервер. Помимо очевидных fetch/XMLHttpRequest и прочих джаваскриптовых штук есть более экзотические способы вроде <img src="...">.

Вчера узнал о ещё более экзотическом и извращённом способе отправки запроса на сервер с помощью CSS:

body::after {
  content: url('...');
}

Этот способ может использоваться для аналитики и трекинга пользователей, у которых отключен JS. Можно отследить клики по ссылкам, ввод текста в инпуты, клики по чекбоксам, длительность ховера на каком-либо элементе; также можно приблизительно определить браузер и операционную систему пользователя. Подробности — https://github.com/jbtronics/CrookedStyleSheets

Защититься от этого можно только отключив CSS. Параноикам пора переходить на текстовые браузеры :–)

У TC39 (технический комитет, разрабатывающий стандарт ECMAScript) появился логотип — https://github.com/tc39/logo

Как амперсанд эволюционировал из латинского et (тот же «и») в отдельный символ

Шпаргалка по основным командам перемещения и удаления текста в терминале (для тех, кто устал от стрелочек или кому было лень специально это гуглить)

Выкатил очередной редизайн своего сайта: http://andrew-r.ru

Главной целью был отказ от Эгеи (движок для ведения блога) и переход на что-то попроще. В итоге пока что использую Jekyll, дальше будет видно, насколько с ним будет удобно жить. Главное — теперь нет стороннего кода и всё под моим контролем, есть простор для кастомизации и экспериментов.

Главный принцип построения архитектуры ПО

Позавчера был мой последний рабочий день в Авито. За год удалось здорово прокачаться во фронтенде, запилить с нуля новый раздел помощи (support.avito.ru) и интегрировать его в мобильные приложения через вебвью, повлиять на развитие общей библиотеки компонентов и нового фронтенд-стека.

Главный вывод, который я сделал — очень многое в работе зависит от команды, это особенно заметно в больших компаниях вроде Авито. Чем сплочённее команда, чем больше в ней единомышленников, тем лучше результат; такой команде не требуется авторитарное управление и навязывание процессов вроде скрама. Если же собрана не очень дружная команда, участники которой не понимают друг друга, результат будет практически нулевым, а попытки навязать команде какие-то процессы скорее всего деморализуют участников и приведут к распаду.

Обратил внимание на UX установщиков программ на винде: установщик весит всего несколько сотен килобайт и скачивается практически моментально, чтобы пользователь сразу открыл его и запустил установку. А скачивание самой программы сделано частью процесса установки, к длительности которого пользователи уже менее требовательны — раз устанавливается, можно подождать.