Самая краткая реализация isDeepEqual?

Столько воды утекло со времен решадоу, а для стилей так никто ничего нормального и не сделал.

Есть vanilla-extract от создателя css-modules, но они не умеют без компайл-тайма работать (а например taddy умеет).

Вообще, я бы не рекомендовал воспринимать мои полуночные посты сильно всерьез. Обычно, я просто делюсь чем-то из моей ночной работы над реатомом и не всегда в этот момент я делаю какие-то обще объективные вещи. * https://t.me/xanf_dev/34

Конкретно isDeepEqual не несет большой полезности и имеет кучу ограничений, вроде отсутсвия сравнения значений Map и Set. Добавил ее просто что бы было. И почему isPlainEqual, а не isShallowEqual?

Но в комментарии пришел @rdvornov и указал на конкретную багу, за что ему спасибо. Сравнение количества ключей не сравнивает их названия и при undefined значении отсутсвующего в другом объекте ключа мы получаем не верный результат.

Первый фикс пришедший мне в голову выглядел так: aKeys.sort().join('') === Object.keys(b).sort().join(‘’), но это совсем не производительно и подумав еще немного нашлось более простое и производительное решение - просто проверяем что каждый ключ итерации одного объекта есть в другом объекте: k in b

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

1) Есть обход коллекции (массив / ключи / итератор)
2) Одно и тоже вычисление с одними и теми же значениями возвращает разный результат, вроде list.map(...).

Уровни погружения в сложность кода

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

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

Разделяется работу со сложностью на три этапа.

1) Дефолты. Определите небольшой набор базовых паттернов, которые успешно покрывают большую часть задач и используйте их при написании нового кода, покрывая success path и особо не думая об оптимизациях. Пример таких паттернов в предыдущем посте.
2) Ревью. Перед коммитом кода пробегитесь пару раз по дифу в стейдже и поревюйте собственные изменения с точки зрения того что можно оптимизировать, что может пойти не так и на что нужно еще тестов добавить. Так же ревью членов команды на ПРе / МРе.
3) Диагностика. Самый правильный способ нахождения проблем и узких мест - запуск кода в реальных условиях. Это может быть как e2e среда тестирования, так и прод - что и когда выбрать отдельная тема. Конкретно для профилирования производительности реакта есть очень мощный react-render-tracker. Больше о тестировании производительности можно почитать Ивана Акулова.

linkedom

https://twitter.com/_arthurdenner/status/1557755997606879233

У меня как-то была задача, решение которой отлично работало в браузере и не работало вовсе или бажило в node-html-parser и jsdom. Не так давно до этого я прочитал статью про linkedom и решил попробовать эту либу. Все завелось и работало отлично, рекомендую!
Из проблем я столкнулся лишь с тем что не все свойства элемента доступны через прямое чтение по названию свойства, но это легко обходится использованием getAttribute.

Я буду в 16-30 рассказывать про #mono

http://ilovefrontend.ru/

Вдруг кому полезно будет.

Вот уже час мой MacBook Air на m1 подключен к Xiaomi Power Bank 3 30000 и заряд ноута не меняется (сижу в браузере и телеге, фоном открыто куча всего).

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

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

UPD. Зарядка с закрытой крышкой:
29% в 16-00
54% в 20-00 (+25 %)
67% в 21-15 (+13%)
На банке все еще мигают 3 индикатора из 4.

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

GraphQL экосистема меня очень сильно раздражает одной простой проблемой - нет легкого клиента для запросов и сабсткрипшенов (без кешей и тп). Ну как нет, вот есть, оказывается, но об этом никто не говорит О_о
Я пользуюсь graphql-request уже очень давно и до сих пор мне не хватало именно подписок. Что ж, посмотрим как оно себя поведет.

P.S. тут и в и дальше в репо можно посмотреть мой старый сетап кодгена для этой либы - мне с ним было хорошо.

P.P.S. чета с того времени либа заметно подросла в размере =(

Именование коммитов

Conventional Commits я сам использую, тк это распространенный стандарт и под них есть тулинг, но лично мне не хватает точности в этом стандарте и я бы хотел видеть такую систему:

Название коммита должно состоять из 4 частей: фича (бизнес-сущность), техническая-сущность, тип изменения, описание (опционально). При этом фича может разделяться (точкой) на подфичи, а описание содержать номер задачи. Первые три части разделяются /, перед описанием ставится двоеточие:


const commitMessage = ${featureName}.${subFeatureName}/${techType}/${changeType}: ${issueNumber} ${description};


Примеры:

shopCard.amount/style/mod: #27 outline - изменили стиль аутлайна для инпута суммы на корзине
shopCard/test/add: #28 snapshots - добавлено снапшот-тестирование для корзины
app/build/fix: #29 reduce bundle size
charts/style/fix: overflow

Технические типы:

logic - business logic of user feature
style - view (UI) of user feature
util - utility functions and services
type - types definition
test - tests for functional
doc - description and specification
example - storybook, docz, etc
deps - third party dependency changes (replaces, forks, API improves)
perf - performance changes
pretty - prettify formating, white-space, missing semi-colons, etc
config: changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm), configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)

Типы модификаций

add - new functional
mod - modifying functional with behavior changes
fix - correcting functional without behavior changes (refactor, inner interface updates)
del - delete functional

Зачем? Такая система очень упрощает чтение истории и поиск по ней, форсит использовать атомарные комиты (надо писать что это и зачем?), позволяет хранить в комит месадже всю информацию об изменении, при этом оставляя его кратким.

P.S. хочу я это с 2019, но все руки не дойдут комитлинт донаписать.