https://t.me/fxnim/51

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

Ну бывает 😓

ну вобще тут история интересная, его изначально для фетча и делали, но по итогу решили сделать как отдельную апи
https://developer.chrome.com/blog/abortable-fetch/#the-history

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

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

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

cc t.me/JentlemanS/205382

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

А ваш? 🙂
firstpr.me

Забавно и по делу https://www.youtube.com/c/Fireship

Ok, вот материал поглубже.

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

А чем события мыши отличаются от событий тача и почему спек последнего несколько (было?)?

О всей этой истории легаси в докладе @rdvornov:

https://youtu.be/4o9joROJVHg?list=PLXObawgXpIfyH7XRtAN1JgFd6FJVzURdV

​​Отличный технический стендап про кодировки — то, как компьютеры хранят и обрабатывают текст и почему раньше мы регулярно сталкивались с «Р·Р°РїСѓСЃРє», «Đ·Đ°Đ¿ÑƒÑ�Đº» и «п╥п╟п©я┐я», а теперь всё норм.

Куча супер классных примеров и баек из жизни. Например, почему концерт Билли Джоэля в Ленинграде называется на всех стриминингах «kohuept» (это в конце восьмидесятых так вбили слово КОНЦЕРТ на латинице) или почему город Aarhus стоит в конце алфавитного списка (виноваты вторая мировая и гугл).

Мечтаю сделать про это эпизод подкаста и не уверен, что у нас получится увлекательнее; целый час удовольствия https://www.youtube.com/watch?v=gd5uJ7Nlvvo

Небольшой ликбез по видам тестирования

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

В зависимости от преследуемых целей тестирования выделяют следующие виды:

Функциональные виды тестирования

Базируются на функциях и особенностях, а также взаимодействии с другими системами. Функциональные виды тестирования рассматривают внешнее поведение системы. Бывают следующие подвиды:

> Функциональное тестирование (Functional testing)
> Тестирование безопасности (Security and Access Control Testing)
> Тестирование взаимодействия (Interoperability Testing)

Более того функциональные виды тестирования могут иметь свои уровни, то есть то, над чем производятся тесты: над отдельным модулем, группой модулей или системой, в целом. Отсюда соответственно выделяют следующие уровни:

> Компонентное или Модульное тестирование (Component Testing or Unit Testing)
> Интеграционное тестирование (Integration Testing)
> Системное тестирование (System Testing)
> Приемочное тестирование (Acceptance Testing)

Нефункциональные виды тестирования

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

> Все виды тестирования производительности:
— нагрузочное тестирование (Performance and Load Testing)
— стрессовое тестирование (Stress Testing)
— тестирование стабильности или надежности (Stability / Reliability Testing)
— объемное тестирование (Volume Testing)
> Тестирование установки (Installation testing)
> Тестирование удобства пользования (Usability Testing)
> Тестирование на отказ и восстановление (Failover and Recovery Testing)
> Конфигурационное тестирование (Configuration Testing)
> Тестирование безопасности (Security and Access Control Testing)

Связанные с изменениями виды тестирования

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

> Дымовое тестирование (Smoke Testing)
> Регрессионное тестирование (Regression Testing)
> Тестирование сборки (Build Verification Test)
> Санитарное тестирование или проверка согласованности/исправности (Sanity Testing)

Хотите узнать больше деталей по каждому виду тестирования? Полистайте www.protesting.ru

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

Локально проблему можно исправить так: type MyPromise<T> = Promise<Awaited<T>>. Почему же не сделать такой тип для Promise по умолчанию?

Ну я проверил, уже с вложенностью в 20 ТС кидает Type instantiation is excessively deep and possibly infinite.

Повспоминаю свои истории косяков немного. Без записи 😁

Самая краткая реализация 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/