Deep Digital

​​Автоплей и режим энергосбережения в iOS 🎥
#frontend

Как известно, современные браузеры не позволяют автоматически проигрывать видео в HTML5-теге <video>, если оно содержит звук или тег не имеет атрибута muted. На этот случай есть некоторые исключения.

Но в Apple iOS пользователей и разработчиков ждет еще один сюрприз, связанный с автопроигрыванием видео. Имя ему — Low Power Mode. При включенном режиме энергосбережения пользователь вместо автоматического проигрывания наблюдает большую серую кнопку Play на видеоблоке. Такой режим включается автоматически при достижении определенного уровня заряда батареи или принудительно, в настройках девайса. Индикатор заряда устройства окрасится в желтый цвет, а все видеоролики на сайтах по умолчанию будут стоять на паузе, даже если не содержат звуковой дорожки.

Обыграть проблему можно с помощью вывода изображения-заглушки поверх плеера, а также скрыв картинку по факту запуска видео, подписавшись на событие play. Например, вот так.

Также можно отрисовать свою собственную кнопку ▶️ или даже реализовать обработку события touchstart у элемента body и запускать видео при касании экрана.

На просторах интернета можно найти больше примеров реализации автопроигрывания видео в режиме энергосбережения iOS.

Чтобы ваш клиент и QA-инженеры были довольны на 100%, предусматривайте описанную ситуацию в своем коде, особенно когда видеоролики являются фоновыми для блоков на странице.

Во всем виноваты объекты[?]
#frontend #reactjs

Хуки, без сомнения, можно назвать главной фичей React-библиотеки. Однако из-за перехода от классовых компонентов к функциональным появился ряд подводных камней. Об одном камушке расскажем далее 👇

Распространенной ошибкой при использовании механизма хуков является неоптимальное применение массива зависимостей. Иногда в зависимостях перечисляют объекты, которые могут стать причиной лишних вычислений и ререндера компонентов.

Например, наш код производит сложнейшие вычисления на основе данных, полученных из локального хранилища 😱

Казалось бы, все правильно: есть сложное вычисление, и мы его мемоизируем. Но если объект data обновится, а значения его свойств count и limit не изменятся, то хук useMemo снова выполнится, вместо того чтобы вернуть уже вычисленное значение, которое также не изменилось.

Это связано с тем, что хуки в своих зависимостях используют для сравнения объектов строгое равенство, не сличая при этом значения свойств.

Решить проблему достаточно легко. Можно заставить хук сравнивать только необходимые нам конечные свойства объекта. Вот так. Теперь useMemo будет вычислять новое значение, только если изменятся свойства count или limit.

Добавлять объекты как зависимости хука нужно только при крайней необходимости. В остальных же случаях лучше использовать примитивы. Мы рекомендуем добавить в проект правила для линтера, которые помогут контролировать использование хуков React.

Лучше поздно, чем никогда: две особенности iOS 13
#qa #frontend

С момента официального релиза Apple iOS 13 по статистике «новая» ОС установлена более чем на 70% поддерживаемых устройств. В этой заметке мы расскажем о двух актуальных для веб-разработчиков особенностях системы, которые вы могли не заметить 😎

Теперь сложно найти рубль 😂
Разработчики iOS 13 стали более строго относиться к отсутствующим символам в шрифтах.

Например, пользователи русскоязычного сегмента интернета после обновления заметили исчезновение символа рубля на некоторых сайтах. Вместо него может отображаться непонятный прямоугольник. Всему виной отсутствие соответствующего глифа в используемых на злополучных сайтах шрифтах.

В прежних версиях iOS поиск отсутствующих символов производился по другим установленным в системе шрифтам. И чаще всего пропажа находилась. В связи с чем найденные глифы могли по-разному отображаться на различных устройствах/браузерах, что доставляло боль QA-инженеру и искушенному пользователю 😱 В iOS 13 от такого поведения случайно или намеренно отказались.

Проблему можно решить самостоятельным редактированием шрифта или более просто — указать в css семейство системных шрифтов.

Say my name
Планшетная версия iOS 13 была переименована в iPadOS 13. Это обусловлено желанием Apple продвигать новые iPad как полноценную замену ПК. В связи с этим заголовок User-Agent http-запроса идентифицирует клиентское устройство как MacOS:

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.0 Safari/605.1.15

В этих условиях отличить iPad от десктопа становится затруднительно, но возможно. Например, так:

const isAppleTouchDevice =
      /(iphone|ipad|ipod)/i.test(navigator.userAgent) ||
      (navigator.platform === 'MacIntel' && navigator.maxTouchPoints > 1);

В JS-коде именно второе условие, после логического «или», проверяет устройство на наличие iPadOS на борту.

Расширяй и властвуй вместе с Pug 🐶
#frontend #js

В Студии мы постоянно стремимся оптимизировать работу, применяя различные инструменты разработки. С недавних пор мы внедрили в корпоративные сборки для статической верстки шаблонизатор Pug.

Его основное преимущество — поддержка использования JavaScript прямо в синтаксисе шаблонов. Можно применять большое количество языковых конструкций, например переменные, классы или функции. Есть возможность делать код более модульным, разделяя его на компоненты — шаблоны и миксины.

Более того, стандартный функционал pug-шаблонов можно самостоятельно расширять. И далее мы расскажем как.

Например, нам очень хочется использовать npm-пакет classname в наших шаблонах. Реализуем его поддержку.

Поскольку Pug компилируется с помощью JavaScript в HTML, мы можем добавить необходимый функционал на этапе сборки проекта, а затем использовать его в шаблонах.

В нашем примере для автоматизации процесса расширения функционала будем использовать таск-менеджер Gulp. Для начала необходимо установить пакет gulp-pug и сконфигурировать его, как описано в документации. Затем с помощью опции locals плагина gulp-pug необходимо определить импортируемые js-переменные или функции, в нашем случае функцию cn. В шаблоне мы сможем вызывать ее из глобального контекста:

header(class=cn('header', { header_auth: auth }))

Пример gulp-задачи, реализующей описанное выше расширение функционала шаблонов, можно посмотреть здесь.

​​Как протестировать iOS и [не]разориться
#frontend #qa

Устройства под управлением Apple iOS генерируют заметную долю трафика в современном интернете. В отличие от остальных мобильных и десктопных операционных систем, все браузеры в iOS работают на движке WebKit. Причем версия движка обновляется только совместно с обновлением самой iOS. В каждой версии WebKit есть признанный список проблем и ограничений, которые так или иначе влияют на рендеринг веб-страниц и их отображение конечному пользователю. А для некоторых легаси-устройств компании Apple уже не предоставляется возможность обновления. Эти факторы сильно осложняют тестирование и отладку веб-приложений на мобильных устройствах Apple.

В Студии QA-специалисты и frontend-разработчики тестируют разрабатываемые сайты минимум в трех актуальных версиях iOS — 11 (2017), 12 (2018) и 13 (2019) — и на различных устройства — Apple iPhone и iPad. Иногда необходима поддержка и более ранних версий iOS — 9 или 10. Все это требует наличия большого количества устройств. При этом за доступ к физическим девайсам идет постоянная борьба среди разработчиков, тестировщиков и дизайнеров 😱

Конечно, проблему можно решить с помощью SaaS, например, того же Browserstack. Об этом мы писали в одной из наших заметок. Недостаток очевиден — это стоимость подписки, которая будет расти с увеличением числа одновременно используемых устройств.

Все специалисты Студии работают на устройствах Apple iMac, операционная система которых предполагает использование среды разработки Xcode. В свою очередь, Xcode содержит приложение Simulator, эмулирующее работу iOS в macOS для мобильных разработчиков.

Внутри симулятора можно запустить веб-браузер Safari, поведение которого будет соответствовать настоящему устройству. В наличии все актуальные версии iOS под любые устройства — даже часы и TV 😎 На одном компьютере разрешается запуск нескольких симуляторов, что может сказаться на производительности вашей операционной системы 😁

На Stackoverflow можно найти удобный список версий Xcode для скачивания и инструкцию по управлению списком устройств.

MS Outlook. Проверяй без отправки
#qa #frontend

MS Outlook, так же как и Internet Explorer, требует особого внимания со стороны QA-специалистов и, конечно же, frontend-разработчиков.

Иногда крупные клиенты требуют полной поддержки MS Outlook при верстке HTML-писем. Этот инструмент со своим встроенным почтовым клиентом является корпоративным для них и обязывает работать именно с ним.

Рассмотрим несколько вариантов организации процесса тестирования корректного отображения писем в MS Outlook.
— «В лоб» — отправляем HTML-письма с одного ящика на другой, работа с которым реализована через Outlook. Это долго, не очень удобно, требует много действий и ожидания доставки писем.
— Можно воспользоваться услугами специальных SaaS, занимающихся организацией маркетинговых email-рассылок. Некоторые такие сервисы, помимо самих рассылок, предоставляют и инструменты для тестирования HTML-писем. Например, Litmus. Основной недостаток — стоимость сервиса, особенно когда у вас нет постоянных потоков верстки писем и организации маркетинговых рассылок.
— Самый интересный и неочевидный 😎 — открыть HTML-документ в Outlook без отправки/приема его в виде письма.

Все три варианта жизнеспособны и могут применяться в различных случаях, в зависимости от массовости, степени доскональности тестирования и прочих условий.

Приведем пример реализации лайфхака с открытием HTML в Outlook 2013. Необходимо выполнить следующие действия:
1. Создать новое сообщение (Главная → Создать сообщение).
2. Вызвать диалог прикрепления файла (Сообщение → Вложить файл).
3. Указать путь к HTML-документу, затем рядом с кнопкой «Вставить» раскрыть выпадающий список и выбрать пункт «Вставить как текст».

Начиная с MS Outlook 2016, механика прикрепления вложений изменилась. Для использования прежнего функционала необходимо настроить панель быстрого доступа, поместив на нее элемент «Вложить файл» (без многоточия). Файл → Параметры → Панель быстрого доступа / Настроить ленту.

Сильно заморочились? Зато теперь мы можем отображать HTML-исходники для письма прямо в MS Outlook, не отправляя его 😊.

Для минимизации возможных проблем с Outlook советуем изначально верстать письма с помощью специализированных фреймворков. В Студии для верстки писем мы используем сборку на основе Foundation for Emails.

​​I'm in ur webapps, checking ur screens
#qa #frontend

Продолжаем цикл рассказов о полезных QA-инструментах. Часто бывает, что в рамках проекта нет возможности производить полноценное развертывание автотестов. При этом объемы мануального тестирования регрессии сайта после каждого его обновления только возрастают.

На помощь приходит BackstopJS. Это бесплатный инструмент на Node.js с открытым исходным кодом, служащий для покрытия вашей верстки автотестами визуального регресса (visual regression testing). Пользоваться им с одинаковым успехом могут как QA-инженеры, так и frontend-разработчики.

Для его применения необходимо написать ряд шаблонных и коротких тестов на JavaScript, в которых требуется указать URL-адреса тестируемых страниц и CSS-селекторы для каждого тестируемого элемента.

BackstopJS взаимодействует с браузерами Chrome/Chromium посредством библиотеки Puppeteer. При выполнении тестов создаются снимки каждого указанного элемента. Далее производится сравнение полученных снапшотов текущей и предыдущей итерации тестирования. При найденных различиях тесты проваливаются.

В стандартный набор BackstopJS входят графические отчеты по результатам каждого теста, возможность запуска браузера в headless-режиме, возможность запуска тестов в готовом docker-окружении для исключения различий в скриншотах между разными системами и многое другое.

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

Make the developer happy!
#backend #frontend #docker

Каждый разработчик знает, что в Студии не приветствуется фраза «У меня локально все работает, а на тестовом серваке — не собирается!».

Ввиду широкого стека разработки и наличия легаси-проектов разработчик не может иметь полный постоянный перечень системных библиотек и библиотек уровня кода. Их версии и состав могут различаться для разного типа проектов.

Например, для сборки frontend-статики в 2017 году мы использовали Node.js v8, в 2019 году — Node.js v11, а сейчас используем v10 и v12.

Более того, окружение системного софта и веб-серверов также различно — для каких-то проектов используется связка Nginx + PHP-FPM, есть несколько старичков на Apache2 + PHP5.6. Для Python Django и Flask — Nginx + Gunicorn.

Для того чтобы окружение программиста было максимально приближено к тестовому/промышленному и он мог жонглировать различными проектами в рамках своей хостовой машины, в локальной разработке мы используем контейнеризацию на основе Docker.

Все сервисы, необходимые для запуска конкретного проекта, описываются в docker-compose.yml, сервисы, необходимые для сборки и отладки проекта, — в файле docker-compose-build.yml. Управление контейнерами производится с помощью утилиты docker-compose. Ну не ставить же каждому разработчику Docker Swarm или K8S 🤔

Таким образом, мы разделяем runtime-контейнеры и контейнеры, необходимые для сборки частей frontend и backend. Конечно, никакого CI/CD тут нет — просто облегчаем жизнь разработчику.

Типовая конфигурация для docker-окружения хранится в корпоративных базовых шаблонах под каждый стек и разновидность веб-сервиса или сайта. Динамические параметры, зависящие от проекта, управляются с помощью удобного механизма переменных окружения и файла .env.

Приятный бонус заключается в том, что для сборки и локального запуска проекта мы заворачиваем соответствующие docker-compose-команды в Makefile. Теперь собрать и запустить проект можно в две команды:

$ make build
$ make up

Например, для запуска простого приложения в связке Nginx + PHP-FPM и сборки frontend-части с помощью Node.js можно использовать эти docker-compose.yml и docker-compose-build.yml. А управлять этими процессами — с помощью этого Makefile.

Упрощайте жизнь разработчикам, чтобы они думали об архитектуре приложения и чистом коде, а не об окружении и запуске 👨‍💻

​​Опасная высота
#qa #frontend

Создавая макеты мобильного адаптива, обычно ориентируются на самые маленькие экраны шириной в 320 px, например как у Apple iPhone 5s. При этом высоту экрана рассчитывают с точки зрения необходимости размещения законченного целостного блока на одном экране и визуального индикатора присутствия скролла «Скролльте вниз».

Здесь может произойти неочевидная подмена характеристик: screen size — размер физического экрана и viewport size — размер его контентной части в окне мобильного браузера.

Первую характеристику указывают во всех спецификациях к устройству, в том числе в браузерных инструментах разработчика при эмуляции мобильных устройств. Однако если в режиме эмуляции для отрисовки сайта доступна вся область экрана, то на реальном устройстве она окажется существенно меньше по высоте, иногда более чем на 100 px. Часть пространства будет отведена интерфейсу браузера и системным элементам, а все, что осталось, и будет являться высотой viewport-области.

Высота viewport-области может меняться даже в рамках одного устройства — при использовании различных браузеров. Более того, она может меняться в процессе навигации по сайту. Например, браузер iOS Safari уменьшает свою панель навигации при скролле вниз, из-за чего могут ложно срабатывать некоторые js-события, отслеживающие ресайз.

Дадим несколько советов, призванных помочь вам в борьбе за функциональность и красоту адаптивов 😉

1. Используйте динамическое позиционирование элемента относительно высоты текущего viewport. Например, блока с иконкой «Скролльте вниз».
2. При тестировании веб-интерфейса создавайте свои шаблоны мобильных устройств в браузерных инструментах с уменьшенной высотой по отношению к стандартным. Например, на 80—100 px меньше.
3. Проверяйте работу интерфейса на реальных устройствах или полноценных симуляторах. Например, Xcode Simulator для iOS.
4. И конечно, учитывайте высоту viewport-области в макетах дизайна.

Вооружен и опасен
#qa #frontend

В процессе тестирования наши QA-инженеры активно применяют различные инструменты. В их число входят и расширения для популярных браузеров. В этой заметке мы рассказали про плагин генерации QR-кодов, а сейчас поделимся и некоторыми другими.

PerfectPixel — позволяет накладывать изображение поверх открытого сайта, регулировать масштаб картинки, позицию и степень прозрачности. Используется по назначению — для максимально точного сравнения макета сайта с его сверстанной версией. В Студии его применяют как QA, так и разработчики.
✅Chrome | ✅Safari | ✅Firefox | ✅Opera | ✅IE | ✅Edge

Form Filler — автоматически заполняет все формы на странице случайными данными, умеет работать с радиокнопками, выпадашками, понимает типы полей. Спасательный круг для тех, кто тонет в тестировании форм, имеет открытый исходный код.
✅Chrome | ✅Edge | ✅Firefox

WhatFont — при клике на текст отрисовывает в этом месте плашку со всей информацией о его шрифте. Пользоваться расширением быстрее и нагляднее, чем инструментами разработчика.
✅Chrome | ✅Safari

Full Page Screen Capture — по нажатии кнопки создает высококачественный скриншот всей страницы, старается учитывать все плавающие элементы в верстке, например шапку. Есть экспорт в .pdf и редактор в платной версии.
✅Chrome

ProKeys — для тех, кто любит много писать. Добавляет в браузер автокомплит текста при вводе кавычек и скобок, как в IDE. Умеет разворачивать любое кодовое слово в произвольный текст на основе шаблона — с поддержкой автоподстановки дат, контента из буфера обмена и быстрой навигацией по маркерам в шаблоне. Расширение полностью настраиваемое и имеет открытый исходный код.
✅Chrome | ✅Opera

Check My Links — проходится по всем ссылкам на странице и проверяет их на валидность. Результат подсвечивается цветом прямо в верстке, есть базовый вывод в лог консоли и возможность экспорта детального отчета в CSV.
✅Chrome

JSONView — расширение форматирует открытый в адресной строке JSON-файл в читабельный и удобный для навигации вид и валидирует его. Полезен при тестировании ответов от RESTful API.
✅Chrome

Bug Magnet — полезный инструмент для проведения исследовательского тестирования форм. Представляет собой набор «плохих», длинных или необычных фраз, невидимых символов, нестандартных языков, текстовых эксплоитов и далее по списку — все то, что потенциально может сломать отправку формы на сайте. Есть возможность расширять базу своими заготовками.
✅Chrome | ✅Firefox

З.Ы. Устанавливайте любые расширения браузера осознанно. Говорят, что некоторые из них могут использовать ваши личные данные и майнить биткоины на ваших машинах 😎 Но это не точно 😉

Ошибки быть не должно!
#frontend #react #nextjs

Когда пользователь взаимодействует с веб-ресурсом, помимо ожидаемого результата, он может наблюдать специальные страницы, отображающие нештатные ситуации в виде http-исключений. Разрабатывая сервисы на Next.js, необходимо управлять выводом таких страниц, анализируя ответы от RESTful API. А с учетом технологии SSR обработчик должен уметь изменять Status Code при отдаче страницы с сервера.

Коробочное решение фреймворка позволяет обработать 404 и 500 http-статусы и кастомизировать вывод страниц для них. При этом обработчик не учитывает случай, когда скрипт страницы загружен, а метод API вернул статус >= 400.

Мы решили отказаться от стандартного способа перехвата и обработки http-исключений в пользу собственного хелпера handleResponseStatus.js.

В хелпере мы учли возможность добавления «глобальных» запросов, таких как авторизация, и «параллельных» запросов, например загрузки меню сайта. Эту задачу решает callback-функция requestFunction, которая возвращает Promise.all. В теле колбека можно контролировать последовательность выполнения с помощью async/await, а в Promise.all — добавлять параллельные запросы.

Осталось привести пример использования хелпера в _app.js и поделиться полезными ссылками 👇

NextJS | getInitialProps
NextJS | Custom Error
ReactDOMServer

Да грузись ты уже 😡
#qa #frontend

Уважающий себя веб-сервис с клиентской браузерной частью немыслим без наличия хорошо проработанной мобильной версии и адаптивности интерфейсов. Такое веб-приложение должно быстро и без сбоев работать в условиях мобильного интернета, с переменной скоростью соединения 3G/LTE-сетей.

Frontend-разработчики часто применяют принцип отложенной загрузки ресурсов для оптимизации скорости подачи контента и функционала пользователю. Сначала показывается только необходимый контент, а тяжелые ресурсы подгружаются асинхронно, в процессе взаимодействия с текущим интерфейсом. Например, когда пользователь сделает скролл до нужного блока.

Такие веб-сервисы важно тестировать в условиях слабого интернет-соединения, эмулируя работу мобильной сети. Проблема может заключаться в подгружаемых в разное время зависимых скриптах.

Представим, что основной скрипт main.js пытается вызвать методы some-library-script.js, которые загружаются асинхронно. Без проверки доступности методов библиотеки или события, срабатывающего на ее загрузку в main.js, пользователь потеряет необходимый ему функционал и не решит свою целевую задачу.

Чем выше скорость интернета — тем больше шансов упустить заветную ошибку.

Начинающий разработчик может неверно реализовать динамическую подгрузку ресурсов, а QA-инженер должен об этом помнить и считать каждого разработчика начинающим 😂

Узнать, как правильно организовать асинхронность загрузки ресурсов, вам помогут полезные ссылки ниже 👇

Lazy Loading Images and Video
Скрипты: async, defer
Dynamic imports

Babel + core-js = ❤️
#frontend #javascript #babel #corejs

Новые js-фичи часто опережают возможности браузеров. Для использования современных конструкций языка разработчикам приходится применять полифилы, настраивать сборщики, проверять поддержку различных методов.

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

Некоторые полифилы могут быть не оптимизированы, что увеличивает размеры бандла и плохо сказывается на общей производительности. Подбор нужного и оптимального полифила может отнимать много времени и стать проблемой для разработчика.

На помощь приходит Babel. Пакет @babel/presset-env подключает необходимые модули библиотеки полифилов core-js, когда в коде используются не поддерживаемые браузерами языковые конструкции. Пресет ориентируется на список браузеров, указанный в package.json.

Чтобы Babel автоматически добавлял нужные полифилы в бандл, нужно создать в корне проекта babel.config.json. Такая конфигурация будет проверять пакеты из node_modules и добавлять полифилы core-js в соответствии с browserlist, указанном в package.json.

Вместо большого количества импортов и отказа от современных методов JavaScript можно добавить всего 14 строк в конфигурацию Babel. Подробнее о конфигурации Babel можно почитать здесь, о полифилах — тут.

Проявляем смеCALCу в препроцессорах
#frontend #css #stylus #sass #less

Функция calc() дает возможность проводить математические операции прямо в CSS, причем передавать в нее можно разные единицы измерения. Чтобы использовать все возможности этой функции, необходимо обращаться из нее к переменным.

Чистый CSS позволяет делать это без проблем — обращение к переменной производится путем вызова функции var():

--offset: 16px;
.block {
  width: calc(100% - var(--offset));
}

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

В SASS для вызова из calc() переменную нужно обернуть в #{ }:

$offset: 16px;
.block {
  width: calc(100% - #{$offset});
}

В Less это делается похожим образом, но строка с calc() экранируется:

@offset: 16px;
.block {
  width: ~"calc(100% - @{offset})";
}

В Stylus синтаксис чуть сложнее:

$offset = 16px;
.block {
  width "calc(100% - %s)" % $offset
}

Если необходимо использовать несколько переменных, Stylus позволяет делать так:

$breadth = 100%;
$offset = 16px;
.block {
  width "calc(%s - %s)" % ($breadth $offset)
}

Что за ссылка такая — ref?
#frontend #react

На собеседованиях мы обычно спрашиваем соискателя, что такое ref в React. Ответ часто таков: «Ref — это ссылка на DOM-узел». Такое определение необратимо устарело с выходом React v16.3.0. Именно в этой версии появилось API для создания объекта ref — React.createRef().

Получение ссылки на DOM-элемент — это всего лишь один из способов использования ref в React API. В более старых версиях React можно встретить методы refs callback для решения данной задачи.

Путаница с рефами стала более очевидной с приходом React Hooks. При изменении состояния функционального компонента может понадобиться не вызывать его повторный рендер. И это задача для рефов!

Например, нам необходимо остановить таймеры, проинициализированные функциями setTimeout или setInterval по клику на кнопку. Использование React.useState() избыточно для решения такой задачи и может ввести в заблуждение других разработчиков.

Из-за большого количества вопросов и issues на GitHub в официальной документации к React Hooks появился подобный вопрос: есть ли что-то вроде переменных экземпляра?https://ru.reactjs.org/docs/hooks-faq.html#is-there-something-like-instance-variables.

Мы рекомендуем именно такое определение: «ref — это объект, а его изменяемое свойство current может хранить в себе любое значение».

Ты видишь LS? — Вот и я не вижу, а он есть!
#qa #frontend

Разработка frontend-части веб-сервиса на основе интерактивных макетов упрощает жизнь верстальщику, позволяя более гибко работать с примитивами. При этом можно столкнуться с некоторыми неочевидными проблемами.

Например, при копировании текста из Sketch-макета и вставке его в верстку встречается «невидимый» символ U+2028. Line Separator реализует перенос последующего за ним текста на новую строку, однако его интерпретация и поведение в обозревателе могут зависеть и от браузера, и от операционной системы. Более того, не все редакторы кода подсвечивают этот символ.

Так, при просмотре верстки в Google Chrome такие символы будут отображаться пользователю как [LSEP] в ОС Windows 10 и [x] в ОС Android. В то время как пользователям MacOS и Windows 7 с применением любых браузеров они просто не видны.

Мы решаем эту проблему с помощью линтера, заменяя или подсвечивая нежелательные символы в коде. Такие символы также идентифицируются при просмотре DOM в Chrome DevTools и отображаются в виде красной точки.

Веб тестируй без труда, на любых устройствах
#qa #frontend

Браузеры на основе Chromium по праву считаются лидерами по числу активных пользователей. Технологии этой платформы применяются даже для создания кроссплатформенных десктопных приложений, например, на фреймворке Electron.

Каждый QA-инженер мечтает об отсутствии других браузеров и движков, в реалиях же имеет целый зоопарк устройств с различными версиями обозревателей. Все это семейство разнородных платформ приходится постоянно поддерживать, следить за совместимостью, обновлять, откатывать и запускать, используя виртуальные машины.

Некоторые QA-специалисты Студии работают в офисе клиента над LTS-продуктами, иногда в другом городе. В таких условиях передача или перевозка физических устройств для тестирования веб-сервисов невозможны.

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

Для того чтобы взаимодействовать с локально развернутыми в тестовом окружении веб-сайтами, облачные сервисы позволяют устанавливать VPN-подобное соединение посредством специального клиентского софта.

Примерами таких SaaS являются BrowserStack, Sauce Labs, LambdaTest. Множество сервисов и конкурентная среда удерживают цены на достаточно демократичном уровне, что позволяет сэкономить в краткосрочной перспективе деньги на физических устройствах.

​​QR на службе у QA
#frontend #qa

Любой веб-разработчик/тестировщик сталкивается с проблемой ввода URL в адресную строку различных мобильных устройств.

Как просматривать многостраничник на трех десктопах и пяти мобильных устройствах и не сойти с ума?

Есть ряд способов упростить задачу передачи ссылок между устройствами, которые решают вопрос частично. Можно использовать сервисы генерации коротких URL и продолжать ручной ввод полученных адресов на разных устройствах. Существуют сервисы синхронизации устройств, что не всегда безопасно, да и одним таким сервисом для зоопарка устройств не обойтись.

Мы решаем эту проблему, используя автогенерацию QR-кодов. Для браузера Google Chrome существует полезное расширение, шифрующее ссылку текущей страницы в QR-код. Далее с помощью любого мобильного устройства сканируем этот код, и вуаля — мы на нужной странице.

Мобильные устройства Apple, начиная с версии iOS 11, нативно имеют встроенный QR-ридер в приложении «Камера». Для Android-устройств используем сторонние приложения из Google Play.

С помощью QR-кодов можно шифровать не только ссылки для перехода, но и текстовые заметки, легко передавая их между устройствами.

Рекомендуем к использованию!