React & Architect

2022-03-29 22:56:51 Лайфхак для ревью:

Когда делаешь ревью, вместо того, чтобы писать "у тебя тут не не правильный код", лучше написать "у этого компонента не правильный код".

Таким образом можно немного сместить акцент с "ты плохой" в сторону "не живых" компонентов/сервисов и т.д.

Хотя это очевидно, что к этим сервисам приложил руку человек и, скорее всего, исполнитель таски тоже. Но все же психологически такая формулировка отвлекает от этого факта и есть шансы, что критика будет воспринята положительно

#code_review Открыть/Комментировать

2020-03-04 10:49:59 Cypress vs TestCafe

Долго ломал голову между тем что выбрать: Cypress или TestCafe.

Пару лет назад я выбрал Cypress для написания тестов для одного проекта. Все было красиво и молодежно, но все же были некоторые проблемы с моками fetch API и тем, что некоторые тесты периодически случайным образом падали. Позднее мне снова потребовалось написать e2e тесты для другого проекта. В этот раз я решил выбрать TestCafe, т.к. этот инструмент тоже весьма популярный, поддерживает, по сути, все браузеры и девайсы и имеет немного другой принцип работы, что открывает потенциально интересные возможности в плане моков. К тому моменту я уже забыл впечатления от Cypress и в целом работа с TestCafe мне показалась вполне комфортной, хоть и немного болезненной. Да, нету красивого интерфейса в браузере, но за то API с православными async/await, а не волшебной очередью, как у Cypress.

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

Но что самое главное, я ощутил насколько приятнее, проще и быстрее работать с Cypress по сравнению с TestCafe. Основная разница заключается в том, что у TestCafe хоть и на первый взгляд более "правильная" апи, но при этом она еще очень "verbose". Тебе нужно все время создавать дополнительные обвертки-объекты для всех сушностей (селектор, мок запросов, логгер запросов (ага, чтобы проверить, что запрос был совершен, тебе нужно его мокнуть, а потом еще отдельно создать логгер, через который можно проверить был ли выполнен запрос), учить немного не типичную API тестов и ассертов. С добавлением суппорта TypeScript в TestCafe тоже пришлось слегка попотеть.

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

Буквально за пару дней я переписал все тесты на Cypress (кстати да, на конвертацию ушло очень мало времени. Думаю, переход с Cypress на TestCafe был бы значительно сложнее) и убедился, что это был правильный выбор. Если какой-то инструмент предоставляет более крутой dev experience и имеет большую комьюнити, лучше всегда отдавать предпочтение именно ему, пока не возникнет ситуация, в которой вы будете вынуждены использовать менее удобные инструменты в пользу их уникальной функциональности без которой вы не сможете достичь своих целей.

Если мне когда-нибудь понадобится выполнять кросс-браузерные тесты, я скорее всего сделаю второй mini-test-suite на TestCafe, который будет покрывать только те кейсы, которые требуют кросс-браузерного тестирования. При этом большая часть тестов все равно останется на Cypress потому, что так быстрее и проще.

А теперь, собственно, о главном в этом посте. Я записал видео сравнение выполнения одного и того же тест сьюта написанного на Cypress и TestCafe. Приятного просмотра! Открыть/Комментировать

2019-11-11 13:28:33 concat vs push

До недавнего времени я всегда отдавал предпочтение Array.prototype.concat, т.к. этот метод не мутирует исходный массив, а immutable ведь модно и надежно. Однако на днях мне пришлось делать циклы по массиву из тысяч элементов и собирать новые массивы на основе данных из этих элементов. Написав первую имплементацию с использованием concat и замерив производительность кода, я обнаружил, что на эти самые циклы со сбором элементов в массивы уходит как-то очень много времени.

Не долго думая я заменил concat на push и скорость выполнения вернулась к более ожидаемым цифрам. Как в последствии оказалось, копировать массивы не такая уж и молниеносная операция для js. Более того, concat поддерживает два типа аргументов: массивы и "все остальное". При чем вы можете передавать сколько угодно аргументов и миксовать их типы. Чтобы поддерживать такую гибкость, скорее всего, под капотом concat перегоняет все аргументы (не зависимо от того, есть ли среди них массивы) в еще один плоский массив, что тоже требует дополнительного времени. Потому, если вам нужно быстро собрать большие массивы данных — используйте Array.prototype.push.

Больше информации, а так же альтернативные, более быстрые имплементации методов push/concat можно подсмотреть здесь Открыть/Комментировать

2019-10-05 09:01:32 Три приема повышения производительности и надёжности приложения

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

Stream или Observable — разгружает компоненты от императивной логики запроса данных и позволяет легко добавлять новые триггеры обновления данных. По сути стримы сделают ваш компонент по настоящему живым и реактивным. Кстати, redux/flux тоже имплементят стримы, но чтобы это все работало, компонент не должен вызывать никаких экшенов для запроса данных — это не его ответственность.

Idle until urgent — это техника, которую предложил Philip Walton из Google. Идея этого подхода в использовании idle периодов браузера для вычислений, которые скоро могут понадобится, и, в итоге, когда юзер совершит нужные действия, он моментально увидит результат. Если выйдет так, что результаты нужны прямо сейчас — вычисления произойдут в режиме лейзилоад. Этот подход позволяет выжать максимум ресурсов из браузера и улучшить ux, при этом не мешая юзеру использовать приложение.

Actor model — это своего рода контракт взаимодействия между модулями, который позволяет распределить вычисления необходимые приложению между воркерами (или вообще кем угодно). При этом основной поток используется исключительно для рендеринга. Этот подход позволяет сделать очень отзывчивый интерфейс, который будет работать на 60 fps. Кстати, этот метод тоже был описан работником Google — Paul Lewis.

В будущих постах я планирую более подробно разобрать каждый из этих пунктов по отдельности и с примерами кода. Открыть/Комментировать

2019-10-02 15:42:48 Эффективный рендеринг в React

Kent C. Dodds на своем блоге снова поднял тему "redux не нужен" и продемонстрировал простую технику, которая позволит ускорить рендер приложения просто за счет того, что вы разместите логику управления стейтом в правильном месте.

Кроме того, ранее Кент опубликовал еще два поста, которые в комбинации с новым представляют очень мощную методологию, которая, в принципе, позволит писать код практически без использования React.memo и сопутствующих хуков.

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

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

2019-10-01 19:35:10 На web.dev запостили информативную статью про оптимизацию скорости первого рендера:

- переиспользование сетевых соединений
- использование preload meta-тегов
- пререндер приложения через puppeteer и инлайн критического кода
- и конечно же code splitting. Из интересного: использование тулзы source-map-explorer для правильного выбора сплит поинтов Открыть/Комментировать

2019-09-28 02:58:24 Проверяйте, что ваш код работает

Наверное, это самый неожиданный первый пост, но все же. Уважаемые подписчики, всегда проверяйте, что ваш код работает, прежде чем отправлять его дальше.

Если быть более точным, вы должны повторить все необходимые действия, чтобы (в идеале) каждая строчка вашего кода исполнилась. Это критически важно — каждая строчка. Пока вы не научитесь выпускать надёжный код, вы можете поставить крест на своей карьере.

Если даже и выйдет так, что вас повысили, то это значит, что вам повезло или вы джуниор. Запрячьте ваше ЧСВ по дальше, если вы хоть раз услышите, что ваш код не работает. Нерабочий код могут выкатывать только уборщицы, т.к. это не их основная деятельность. Открыть/Комментировать

2019-09-01 19:33:59 Привет, мир. Давайте знакомиться!

Я занимаюсь web с 2007 года. Профессионально — c 2013 года (фронтенд и бекенд). Кроме того, я люблю фронтенд и React в частности.

Я верю, что писать серьезные и качественные проекты на React должно быть легко и приносить удовольствие. Именно эту цель я сейчас поставил перед собой и постараюсь поделиться всей информацией и опытом с вами. Это будет как и мой опыт так и просто ссылки на интересные статьи, возможно, с моими комментариями.

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

И еще один момент. Это мой первый канал, так что не судите строго Очень надеюсь, что все останутся довольны! Открыть/Комментировать