Поговорим сейчас в войсе с @nin_jin про обработку ошибок в реактивных графах

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

Если во время написания и множественных перезапусков тестов обнаружилась ошибка кеша апишки, стоит ли это включать в тест?)

Правильный ответ - стоит включать в нагрузочное тестирование. А если его нет, стоит ли раздувать бизнесовые тесты?

Дауж, cypress это тот еще склад костылей. Хотя, не то что бы это его вина.

Задача проще некуда - изменить значение в инпуте. Не с клавиатуры, а целиком заменить (а что если пользователь делает ctrl+A, ctrl+V). Заклинание выглядит так: .invoke('val', newValue). Работает? Да. А если палочкой потыкать? Нет.

Оказывается, реакт на такое изменение не тригериться. Как ему подсказать? В ишье предлагают события тригерить. Правда, какие - не ясно. Что-то у кого-то работает, что-то нет.

Я придумал простое .type("0{backspace}”). Работает? Да. А если палочкой потыкать? Да. А если другой палочкой потыкать? Нет. Что?

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

Окидокики, текстария в которой все работало маунтилась прям перед изменением, а не работало там где компонент уже давно лежал в дереве. Не уверен что там именно происходит, да и не хочу, мб файнал форм на фокус что-то ререндерит.
Но пофиксил добавлением focus() перед invoke.

На прошлой неделе я болел, поэтому было тихо.

Что-то мне в голову стрельнуло, попытаюсь каждый день делать какой-то пост. Нужно еще время выбрать, скорее всего это будет 11-00 по gmt-3.

С самого начала у меня были претензии к системе модулей ЖС в том что она не позволяет полностью заменить IoC / DI.

Яркий пример, почему это проблема - jest.mock. Необходимость в таком инструменте уже говорит о том что с архитектурой что-то не так. Ну и с нативными импортами оно ломается (на сколько я знаю, мб что-то поменялось).

Сейчас разрабатывается предложение import-maps, но полноценный DI оно заменить не сможет.

Почему я вообще думаю что это должно быть в платформе? Потому что это базовый паттерн и мешаться он точно не будет. И текущие решения ни разу не lightweight и зависят от нестандартизированных компайл-тайм апишек.

P.S. или не нужно было импорты модулями обзывать, это какой-то file linker, не знаю.

Затравка перед завтрашним постом 🙂 на скрине неудачная попытка микрооптимизации бандлсайза.

reduce nanoid bundlesize

Это уже становится хобби 🙂 Захожу раз в несколько месяцев в нано библиотеки Андрея Ситника и пытаюсь придумать как бы уменьшить их бандлсайз.

Это особенно увлекательно из-за того что Андрей сам большой спец в этом вопросе и найти какие-то оптимизации каждый раз очень сложно.

Вчера посчастливилось придумать оптимизацию, которая срезает 12% размера nanoid - доволен как слон 🤗

Кому интересны детали, обратите внимание на то что коммита два.

CSS-lock / CSS-шлюзы

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

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

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

Базовый принцип такой: берем среднюю (медианную) ширину экрана целевой аудитории, под которую будем верстать, переводим 16px (базовый размер шрифта) в vw: для 1600px - это 1vw, для 1336px (стандартное для windows ноутбуков) - это 1.2vw и выставляем как font-size на html.
Теперь, чем меньше или больше будет размер экрана отличаться от базовой ширины, тем сильнее будет меняться и размер шрифта, что будет отражаться на всей нашей верстки, если мы будем описывать все размеры в em.

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

html { 
  font-size: clamp(0.7em, calc(0.5vw + 0.7em), 1.4em);
}

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

Очередная жертва дефолтных экспортов. Комичность еще и в том что импорт в модуле добавления рекламного тега - AddTag (неймспейс adTags), из-за чего становится совсем не ясно, нарочно ли был импорт так назван.

Я был сильно не прав, useEffect не вызывается лишний раз.

Очень стыдно, простите 🙃

Избыточно перевызываться могут только хуки мемоизации.

За поправку спасибо @BuggyTheClown.

Но я еще подкину интересного по теме: Design decision: why do we need the stale closure problem in the first place? Старый и до сих пор не закрытый ишьес, в котором можно найти много занятный примеров. Может, повычитываю его потом повнимательней и скину сюда самое интересное.

UPD: useEffect без зависимостей все же может вызываться дважды в девелопе со стрикт модом.