JavaScript *

Предлагаем вашему вниманию подборку с ссылками на новые материалы из области фронтенда и около него.

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

1. Зачем мы пишем тесты?
2. Какие бывают тесты?
3. Как мы пишем тесты?
4. Как их стоит писать?
5. Почему модульные тесты — это плохо?

Привет. Как-то еще давно мне захотелось пройти тест по js-у. Мой выбор пал на центр сертификации от одной крупной компании. Что из этого вышло, можно прочитать в моей статье.

Привет, Хабр! Представляю вашему вниманию перевод статьи "RxJS: Don’t Unsubscribe" автора Ben Lesh.

Ну… ладно, просто не отказывайся от подписок.

Я часто помогаю кому-нибудь в отладке проблем с их RxJS кодом, в том числе со структурированием приложений, которые несут в себе много асинхронного кода. При этом я всегда вижу одно и тоже, как люди держат обработчики на тоннах подписок. Разработчик делает 3 HTTP-запроса с Observable, сохраняя 3 объекта подписки, которые будут вызваны, когда произойдет какое-то событие.

Я знаю, почему так происходит. Люди привыкли использовать `addEventListener` N раз, а затем, когда они больше не нужны, вызывать `removeEventListener` N раз. Естественным будет делать то же самое и с объектами-подписками, и по большей части вы будете правы. Но есть и лучшие способы. Сохранение слишком большого количества объектов подписок — это знак того, что вы управляете своими подписками императивно и не пользуетесь преимуществами Rx.

В предыдущей части туториала мы научили наше изоморфное приложение проксировать запросы к backend api, с помощью сессии передавать начальный стейт между синхронными запросами и осуществлять Server-side rendering с возможностью переиспользования разметки на клиенте (hydrate). В этой части мы решим еще две ключевые проблемы изоморфных веб-приложений: изоморфный роутинг и навигация, и повторный фетчинг и начальное состояние данных. И сделаем это буквально 5-ю строками кода. Погнали!

Сегодня, в переводе десятого материала из серии, посвящённой особенностям работы механизмов JavaScript, мы расскажем о том, как отслеживать изменения в DOM с помощью API MutationObserver.

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



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

Наше внутреннее Front-end сообщество в Райффайзенбанке активно развивается, коллеги регулярно встречаются для обмена опытом и полезными полезными знаниями. Мы знаем, как важно общаться с людьми из других команд и проектов, иметь возможность спросить совета, обсуждать только что появившиеся технологии и поделиться опытом. Поэтому 28 марта мы организуем Front-End MeetUp. Приглашаем спикеров! Подробности под катом.

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

Материал, посвящённый переменным окружения в Node.js, перевод которого мы сегодня публикуем, написал Берк Холланд, веб-разработчик, в сферу интересов которого входят JavaScript, Node.js и VS Code. Кроме того, стоит отметить, что у него сложились непростые отношения с Java. Вот его история.

Переменные окружения — одна из фундаментальных конструкций среды Node.js, но почему-то я никогда не стремился научиться правильно ими пользоваться. Возможно, случилось так из-за их названия — «Environment Variables». Это название вызывало у меня нечто вроде посттравматического синдрома, неприятные воспоминания о том, как я пытался добавить путь к домашней директории Java в Windows. Я тогда толком не мог понять, надо ли добавлять этот путь в переменную PATH, в переменную JAVA_HOME, или и туда и туда. Было неясно и то, нужно ли, чтобы в конце этого пути стояла точка с запятой. Собственно говоря, тогда у меня возникал и вопрос о том, почему я использую Java. Как бы там ни было, я наконец нашёл в себе силы и приступил к знакомству с переменными окружения Node.



Если вы пишете для платформы Node.js, и, так же, как и я, неважно — по каким причинам, до сих пор не особенно хорошо знакомы с переменными окружения — предлагаю это исправить.

Если вспомнить все ТЗ с описаниями валидации полей — они всегда выглядили примерно так:

• не должно быть короче 6 символов
• не должно превышать 12 символов
• должно включать только латинские символы, цифры и знак подчёркивания

Требования часто приходят набором простых однозначных фраз. А мы, программисты, переводим эти требования в код.

Можно превращать их в одно ультимативное регулярное выражение, вроде

const validateLogin = login => /^[a-zA-z_\d]{6,12}$/.test(login);

Но лучше писать более простые функций которые легче читать и связывать с непосредственным ТЗ:

const charMatch = new RegExp('^[a-zA-Z_0-9]*$');
const validateLogin = login => {
    if (login.length < 6) return false;
    if (login.length > 12) return false;
    if (!charMatch.test(login)) return false;
    return true;
};

А что если ещё сильнее упростить этот код до чего-то вроде:

const validateLogin = login => 
  validate(login)
    .notLessThan(6)
    .notLongerThan(12)
    .hasOnly(['a-z','A-Z','0-9','_']);

WebRTC — не самая простая штука. Только недавно API стали поддерживать все основные браузеры, но с оговорками и «нюансами». Добавим к этому темное наследие VoIP телефонии в виде торчащего наружу SIP, борьбу между Ёжиком и SIP с применением oRTC, падающие при неудачном сочетании звезд браузеры — и получаем штуку, которую не в любом коворкинге за вечер запилишь. Цахи, бессменный автор bloggeek.me и старый телеком-разработчик, продолжает писать как все это правильно готовить. А мы в Voximplant адаптируем перевод для Хабра, основываясь на собственном многолетнем опыте голосовых и видеозвонков с участием браузеров.

Любой redux разработчик расскажет вам, что одной из самых тяжелейших частей разработки приложений являются асинхронные вызовы — как вы будете обрабатывать реквесты, таймауты и другие коллбэки без усложнения redux действий(actions) и редьюсеров(reducers).

В этой статье я опишу несколько различных подходов к управлению асинхронностью в вашем приложении, начиная от простых подходов как redux-thunk, заканчивая более продвинутыми библиотеками вроде redux-saga.

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

Если вы попали сюда по запросу типа «какого черта мой сервис воркер не работает на продакшене?», добро пожаловать под кат.

В этой статье я хочу рассказать о нас и о том, как мы делаем AB-DOC — бессерверное веб-приложение, предоставляющее интерфейс к хранилищу Amazon S3. Подробнее про AB-DOC можно почитать в нашей предыдущей статье. Сейчас речь пойдет о технологических решениях, которые лежат в основе AB-DOC. Расскажу, как мы построили процесс разработки и развертывания.



На фото я за рабочим столом у себя дома, где я работаю 90% времени.

React представляет новое API (context API), которое использует "паттерн" (шаблон) render props (подробнее). На семинарах, встречах и в твиттере я вижу, что возникает много вопросов об использовании render props вне рендера, например, в обработчиках событий или "хуках" жизненного цикла(`lifecycle hooks').

Тестировать регресс верстки скриншотами модно, этим никого не удивишь. Мы давно хотели внедрить этот вид тестирования у себя. Всё время смущали вопросы простоты поддержки и применения, но в большей степени — пропускная способность решений. Хотелось, чтобы это было что-то простое в использовании и быстрое в работе. Готовые решения не подошли, и мы взялись делать свое.

Под катом расскажем, что из этого вышло, какие задачи решали, и как мы добились того, чтобы тестирование скриншотами практически не влияло на общее время прохождения тестов. Этот пост — расшифровка доклада, который прозвучал на HolyJS 2017 Moscow. Видео можно посмотреть по ссылке, а почитать и посмотреть слайды — далее.

Автор: Николай Хабаров, IoT Google Developer Expert, эксперт по встраиваемым системам, DataArt.

В этой статье я расскажу, как создать собственное устройство с веб-интерфейсом, которое будет доступно в локальной сети. Веб-интерфейс будет показывать текущие данные с датчика Si7021: температуру и влажность.

Устройство работает на основе микроконтроллера ESP8266 (с Wi-Fi) и прошивки DeviceHive.

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



Сегодня, во второй части перевода, Томаш Рудски расскажет о наиболее распространённых SEO-ошибках, которым подвержены сайты, основанные на JavaScript, обсудит последствия грядущего отказа Google от механизма AJAX-сканирования, поговорит о предварительном рендеринге и об изоморфном JavaScript, поделится результатами экспериментов по индексированию. Здесь, кроме того, он затронет тему особенностей ранжирования сайтов различных видов и предложит вспомнить о том, что помимо Google есть и другие поисковики, которым тоже приходится сталкиваться с веб-страницами, основанными на JS.

В конце месяца пройдет первый Московский MeetUp, посвященный исключительно фреймворку Vue.js.

На мероприятие приглашаются все заинтересованные разработчики – от начинающих до опытных. Мы будем обсуждать самые разные вопросы применения Vue.js, а спикеры и гости мероприятия поделятся реальными приёмами и практическими примерами. И все это в приятной атмосфере с кофе и печеньками.

Мы ждем вас 22 марта 2018 в офисе компании Acronis — в Физтехпарке (г. Москва, Долгопрудненское шоссе, д.3). Специально по этому случаю будет организован трансфер от станции метро Алтуфьево, а также возвращение в город после мероприятия.

Появляется все больше SPA салонов. Даже лендинги люди пилят на React. А действительно сложное веб-приложение уже трудно представить с другим подходом. Одна из главных проблем современного фронтенда — это сборка таких проектов. С этим помогают справляться бандлеры.

Иван Соснин, фронтенд-разработчик Контура, рассказывает как настроить webpack 2 и 3, чтобы получить ощутимый прирост в скорости сборки статики. Статья будет полезна тем, кто уже работает с webpack или смотрит в его сторону.

Стоит начать с ремарки, что недавно вышел webpack 4. Там вообще все супербыстро и ничего делать не надо, а еще изменилось процесс разбиения кода на чанки.

Но тащить в продакшен библиотеки, которые обновились вчера — не мой путь.

Webpack — это сборщик модулей (бандлер). Он собирает различные модули с зависимостями в один или несколько файлов (бандлов). У webpack модульная архитектура, а это значит, что его можно гибко настраивать. Сборка кода настраивается при помощи плагинов, а трансформации кода производятся с помощью загрузчиков (loaders).

Если хочется больше базовых подробностей, можно почитать статью Рахима Давлеткалиева про webpack 1. Она немного устаревшая, но идеи и примеры в ней разобраны подробно.

За всю эту гибкость приходится платить сложной конфигурацией.