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

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

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

Дауж, 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 без зависимостей все же может вызываться дважды в девелопе со стрикт модом.

Resumability: a no-overhead alternative to hydration

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

Напомню проблему: всякие реакты и даже свелт после загрузки HTML от SSG / SSR предполагают загрузку его копии внутри JS в виде шаблонов, для построение биндингов к дому. Выглядит очень избыточно и статья о том и говорит. А еще это способствует не гранулярной работе с ДОМом и последующим томозам в рантайме.

Проблема делать иначе в том что для построения биндингов ЖСа к событиям и атрибутам ДОМа без наличия всего тела темплейта нужен достаточно хитрый компайлер, который все равно будет вас сильно ограничивать.

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

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

Будет чудо, если в этом году я найду время на то что бы этим заняться 👀

rome.tools

Идея унифицированного инструмента для всех AOT (билд-тайм) преобразований очень здравая, зачем парсить текст и выделять семантику несколько раз. За Ромом стоят опытные разработчики (автор Babel), они уже подняли инвестиции и все бы ничего… Но продукта небыло очень долго и лично меня это сильно смущает. Говорят много, пощупать можно было мало. Два года потребовалось что бы выпустить форматтер, о котором я сегодня и хотел рассказать.

Начал понемногу пробовать его через расширение для vscode на реатоме, скорее по фану, пока что. Но оно preview, не отрабатывает и не пишет ошибки в output, если таковые есть - просто ничего не происходит. В плейграунде можно увидеть ошибки, но я вот вставил туда 600 строк кода и интерфейс фризится на секунды на моем m1.

Разницу с prettier можно увидеть тут. Правда, туда залетели дефолтные табы, использование которых странно для тех кто близок к OSS и гитхабу и знает как ужасно они там отображаются.

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