Пробежался про статье и похоже она устарела на несколько лет. Написана плохо. В худших традициях "сео" контента. Много повторений.
Не рассмотрены причины, по которым многие разработчики начинают костылить собственные решения.
Последние годы набирают популярность headless решения. Можно посмотреть в сторону react-aria, например. У таких решений преимущества готовых библиотек и возможности как у разработки с нуля
У меня были вторые, как же я радовался. Потом утопил их в море, взял четвёртые. И да, возненавидел их. Ось новая, сырая, разряжаются всегда внезапно. Потом ещё сами Самсунг убили экосистему. Недавно был вал отзывов с единицей на приложение, потому что они просто сломали сопряжение с телефоном. А ведь стоят недешево. На Авито дай бог за треть цены теперь продать. Мусор, а не часы. Я уж молчу, что некоторые топовые фишки либо в России не работают, либо не работают без телефона Самсунг
Непонятно, почему в данном случае вы выставляете крайним аналитика. Она на собеседовании себя сеньором выставила? Нет. Почему вообще джун, которому платят за и не увольняют, принимать импульсивные решения в духе "я не приношу пользы, я ухожу"? Это проблема бизнеса. Потому что как только такой джун хлопнет дверью, на его месте появится другой. И в отличие от этого джуна, который погружён в проекты и архитектуру, первым вопросом новичка будет "а как вас зовут?"
При чём тут мокирование? Если у меня, условно, импорт компонента из mui, то он совершенно обычно зарезолвится в тестовом окружении.
Ровно то же плохое, что и в лопаньи пузырьков на пленке
Неостроумные аналогии не по делу - вот что бесполезно.
Какое отношение это всё имеет к rtl и статье?
Самое прямое. Речь о тестировании.
Когда сторона тестов дёргает сторону тестируемого кода через селекторы, завязывающиеся на конкретные теги, классы, или (обоже) тексты — вам неизбежно придётся писать "странные и бесполезные" тесты
Вам стоит ознакомиться с философией и позиционированием rtl. С семантикой в html, с доступностью. И потом писать что-то в духе того, что тесты построены не нестабильных селекторах классов. И да, какая проблема с текстами? Если есть intl с дефолтными стрингами, которые, как правило, не меняются. А реальные переводы лежат отдельно или запрашиваются с сервера.
Большинство описанных проблем решены несколько лет назад и активно используется очень многими разработчиками, которые по вашему мнению "лопают пузырики". Пожалуй, только в русском сообществе можно встретить настолько некомпетентное, но переполненное важностью, мнение.
Соглашусь в одном - логику из компонентов нужно выносить.
Во-первых, в контексте rtl тестирование компонентов уже не является юнит. Т.к. рендерит все потомки тестируемого компонента. Во-вторых, что плохого в покрытии веток кода тестами? В-третьих, е2 тесты все равно должны быть. То есть всегда можно выбрать другие типы тестирования не взамен, а в помощь.
дык, при потреблении федерализации откуда типы брать? насколько помню, официальный ответ на гитхабе был в духе "нет совместимости с тайпскриптом". Ну и нет совместимости у федерализации с остальными сборщиками. Что привязывает консьюмеров к вебпаку. Хотя нормального экспорта в esm у вебпака по-моему до сих пор нет. Активно тестят и пишут в соответствующий ишью на гх, слежу в полглаза, но кажется, всё ещё не для прода.
Ну и в целом мне кажется устаревшим подход вебпака к постоению зависимостей. Например, все модули лежат по номерными ключами в глобальном объекте. Не знаю, как в пятой версии, а в четвёрке была проблема с двумя фронтами на одной странице - вебпак одного затирал объект зависимостей другого.
В общем, полно там проблем. Часть из них легаси, часть из них вызвано тем, что вебпак не умеет в esm. а нативные модули уже давно поддерживаются везде + работают из коробки.
Ну и возвращаясь к типам - чтобы консьюмить модули с типами, генерю для каждого модуля d.ts и кладу его в кастомную папку с типами, которая работает как node_modules, импортирую модули как обычные модули из node_modules, в мапингах зависимостей коллбек в духе "если модуль начинается с project-name-*, то рерайтим импорт "вот так". Где "вот так" - динамический импорт esm. Да, он возвращает промис, то top level await тоже уже давно не диковинка.
Мне не понравилась федерализация. Топорно, сложно, тяжело типизировать. Если нет требования поддержки старых браузеров, проще построить расширения на базе обычных esm. Гибкости больше. И контроля.
Не буду ничего комментировать. Вы постоянно меняете аргументы.
Я лучше подожду, когда вы напишите, какие конкретно статьи и каких законов были нарушены и дадите оценку соглашению пользователя cs-cart (или как там называется).
Тогда будет хоть какой-то намёк на конструктив, а не эмоции и обвинения в духе «а если бы».
я вебвизором не пользовался уже года три, но когда пользовался, он именно что собирал данные форм. Там был встроенный кейлоггер по сути.
Поэтому аргументация в стиле «если бы… то стоял бы вой на весь мир» не работает.
Материал интересный, но оформлен в лучших традициях жёлтой прессы.
"Накоплена база". Есть основания полагать, что результат генерации бессрочно хранится?
Утечка счетов - утечка это нечто незапланированное. По факту мы видим абсолютно штатную работу системы. Возможно нарушающую какие-то законы. И то, если об этом не сказано в каком-нибудь их соглашении пользователя.
Какие счета под угрозой - тоже не видно из материала.
У шопифай вообще все магазины на своих серверах. Можете следующую статью назвать "утечка счетов миллионов магаизнов первого по популярности движка екомерс"
Или ещё лучше "троян: разработчики встроили в свой продукт облако"
Пробежался про статье и похоже она устарела на несколько лет. Написана плохо. В худших традициях "сео" контента. Много повторений.
Не рассмотрены причины, по которым многие разработчики начинают костылить собственные решения.
Последние годы набирают популярность headless решения. Можно посмотреть в сторону react-aria, например. У таких решений преимущества готовых библиотек и возможности как у разработки с нуля
У меня были вторые, как же я радовался. Потом утопил их в море, взял четвёртые. И да, возненавидел их. Ось новая, сырая, разряжаются всегда внезапно. Потом ещё сами Самсунг убили экосистему. Недавно был вал отзывов с единицей на приложение, потому что они просто сломали сопряжение с телефоном. А ведь стоят недешево. На Авито дай бог за треть цены теперь продать. Мусор, а не часы. Я уж молчу, что некоторые топовые фишки либо в России не работают, либо не работают без телефона Самсунг
Непонятно, почему в данном случае вы выставляете крайним аналитика. Она на собеседовании себя сеньором выставила? Нет. Почему вообще джун, которому платят за и не увольняют, принимать импульсивные решения в духе "я не приношу пользы, я ухожу"? Это проблема бизнеса. Потому что как только такой джун хлопнет дверью, на его месте появится другой. И в отличие от этого джуна, который погружён в проекты и архитектуру, первым вопросом новичка будет "а как вас зовут?"
При чём тут мокирование? Если у меня, условно, импорт компонента из mui, то он совершенно обычно зарезолвится в тестовом окружении.
Неостроумные аналогии не по делу - вот что бесполезно.
Самое прямое. Речь о тестировании.
Вам стоит ознакомиться с философией и позиционированием rtl. С семантикой в html, с доступностью. И потом писать что-то в духе того, что тесты построены не нестабильных селекторах классов. И да, какая проблема с текстами? Если есть intl с дефолтными стрингами, которые, как правило, не меняются. А реальные переводы лежат отдельно или запрашиваются с сервера.
Большинство описанных проблем решены несколько лет назад и активно используется очень многими разработчиками, которые по вашему мнению "лопают пузырики". Пожалуй, только в русском сообществе можно встретить настолько некомпетентное, но переполненное важностью, мнение.
Соглашусь в одном - логику из компонентов нужно выносить.
Во-первых, в контексте rtl тестирование компонентов уже не является юнит. Т.к. рендерит все потомки тестируемого компонента. Во-вторых, что плохого в покрытии веток кода тестами? В-третьих, е2 тесты все равно должны быть. То есть всегда можно выбрать другие типы тестирования не взамен, а в помощь.
дык, при потреблении федерализации откуда типы брать? насколько помню, официальный ответ на гитхабе был в духе "нет совместимости с тайпскриптом". Ну и нет совместимости у федерализации с остальными сборщиками. Что привязывает консьюмеров к вебпаку. Хотя нормального экспорта в esm у вебпака по-моему до сих пор нет. Активно тестят и пишут в соответствующий ишью на гх, слежу в полглаза, но кажется, всё ещё не для прода.
Ну и в целом мне кажется устаревшим подход вебпака к постоению зависимостей. Например, все модули лежат по номерными ключами в глобальном объекте. Не знаю, как в пятой версии, а в четвёрке была проблема с двумя фронтами на одной странице - вебпак одного затирал объект зависимостей другого.
В общем, полно там проблем. Часть из них легаси, часть из них вызвано тем, что вебпак не умеет в esm. а нативные модули уже давно поддерживаются везде + работают из коробки.
Ну и возвращаясь к типам - чтобы консьюмить модули с типами, генерю для каждого модуля d.ts и кладу его в кастомную папку с типами, которая работает как node_modules, импортирую модули как обычные модули из node_modules, в мапингах зависимостей коллбек в духе "если модуль начинается с project-name-*, то рерайтим импорт "вот так". Где "вот так" - динамический импорт esm. Да, он возвращает промис, то top level await тоже уже давно не диковинка.
Мне не понравилась федерализация. Топорно, сложно, тяжело типизировать. Если нет требования поддержки старых браузеров, проще построить расширения на базе обычных esm. Гибкости больше. И контроля.
Я лучше подожду, когда вы напишите, какие конкретно статьи и каких законов были нарушены и дадите оценку соглашению пользователя cs-cart (или как там называется).
Тогда будет хоть какой-то намёк на конструктив, а не эмоции и обвинения в духе «а если бы».
Поэтому аргументация в стиле «если бы… то стоял бы вой на весь мир» не работает.
ЗЫ: yandex.ru/support/metrica/webvisor-v2/settings.html
Материал интересный, но оформлен в лучших традициях жёлтой прессы.
"Накоплена база". Есть основания полагать, что результат генерации бессрочно хранится?
Утечка счетов - утечка это нечто незапланированное. По факту мы видим абсолютно штатную работу системы. Возможно нарушающую какие-то законы. И то, если об этом не сказано в каком-нибудь их соглашении пользователя.
Какие счета под угрозой - тоже не видно из материала.
У шопифай вообще все магазины на своих серверах. Можете следующую статью назвать "утечка счетов миллионов магаизнов первого по популярности движка екомерс"
Или ещё лучше "троян: разработчики встроили в свой продукт облако"