Мне казалось, что чтобы вырасти из миддла в синьоры нужны паттерны. Читал много книг, делал в разных паттернах решение одной и той же задачи, сравнивал перфоманс, масштрабируемость, DX и т.п. Но на протяжении последующих лет пригодились только в обсуждениях в чатах + для общего развития мышления. В реальности нужно совсем другое - абстракция сложности и понятность кода. Первое подразумевает, что можно в выделенной библиотеке писать так, чтобы тебе было понятно, а в коде проекта - чтобы было понятно джуну. Если проект долгоживущий - добавляешь к библиотекам документацию, чем руководствовался при выборе таких подходов, чтобы пришедшие на смену архитекторы могли дорабатывать либо переписывать по своему усмотрению, но код проекта оставался бы таким же простым.
Поэтому все же я думаю, что спрашивать про паттерны не надо ни джунов, ни синьоров, но миддлов погонять можно - это покажет кругозор
Спасибо за статью, прямо с языка все сняли. Сколько ни работал в небольших компаниях и стартапах - история везде одинаковая. Совмещение нескольких должностей, переработки, обещание золотых гор (вам повезло по поводу реальных выплат премий - на моей практике это исключительный случай), абсолютно нереалистичные ожидания с мотивацией "нам надо бежать еще быстрее, чтобы всех перегнать", малое внимание к качеству и стабильности продукта, "мнение начальства непререкаемо", нехватка специалистов, часто - отсутствие отпусков, высокая текучка. Это характерно не только для российских контор - в зарубежных часто не лучше, но как правило более демократично (более горизонтальные структуры).
Я тоже из-за внутреннего чувства ответственности и на ранних стадиях из-за обещаний "золотых гор" выжимался в каждой из компаний, да и сейчас продолжаю в точно такой же ситуации. Но внутренних ресурсов все меньше, а раздражения все больше, отчего иногда становлюсь "токсичным". Все еще надеюсь, что найду нормальную компанию (в крупных конторах действительно было намного спокойнее).
Вариант лучше, без дополнительных классов/data-theme/отдельных параметров --color-dark/--color-light, за которыми еще и нужно следить для избежания коллизий имен - это CSS variables записывать напрямую в <html style="--color-primary=#ccc"> . При смене темы соответственно менять их значения там же. И только для исключительных случаев (разная логика в разных темах) пригодится глобальный идентификатор в виде класса или data-theme. Таким образом значительно уменьшится количество кода и не нужно в стилях прописывать дополнительные служебные переменные
Надо упомянуть, что схема не будет работать с SSR - кука будет прикреплена к домену jsonplaceholder.typicode.com , а не домену фронта, так что node-сервер не сможет ее получить и зафорвардить в апи. Также и из локалстораджа он не получит токен. То есть для SSR юзер всегда будет неавторизован. Конечно, для авторизованных зон SSR зачастую избыточен, но ряд сайтов (маркетплейсы, к примеру) от этого пострадают, хотя и не слишком сильно.
На Хабре обсуждалось не раз предложение "сделать единое AST для TS, ESLint, Webpack и других сборщиков, переиспользовать в IDE", вроде вы тоже участвовали в обсуждениях. Но каждый раз приходим к тому, что есть разные лицензии, корпоративные политики (TS), ограничения операционных систем, разность механик работы разных инструментов. Я тоже хотел бы видеть "универсальный процесс, генерирующий универсальное дерево с адаптером ко всем языкам программирования", это был бы, наверное, лучший вклад в экосистему разработки за десятилетия, но остается только мечтать...
Только начал всю эту канитель, вроде как можно не 8 лет для подтверждения квалификации, а 6 + описание проектов на полкниги. Надеюсь на удачу, что 70-75 баллов каким-то образом стрельнут, также думаю проработать вариант с удаленной работой на австралийскую контору - может тоже зачтется. Спасибо за опыт, креплюсь)
Самое главное забыли - в ряде случаев (когда они появились - практически во всех браузерах так было) у стрелочной функции нет name, `const fn = () => false`, fn.name undefined|''. То есть в стек-трейсе будет anonymous, и если код минифицирован, найти причину бага очень сложно. Но в современных браузерах name назначается по имени константы. Это все еще приходится держать в голове. В определенных случаях и современные браузеры не назначат - `const fn = (() => () => { return false })()`.
Также стрелочные функции, назначенные как константы, нельзя использовать выше их объявления, в отличие от именованных. То есть в ряде случаев придется жонглировать местами объявления.
Еще натыкался на то, что стрелочные методы классов в определенных версиях транспиляторов не декорируются, так как на выходе код совершенно другой, чем у нестрелочного метода.
Фича в целом отличная, но об ограничениях нужно помнить
Чтобы написать достаточно полные описания, по которым ИИ сможет сгенерировать достаточно полноценный код, труда надо намного больше, потому что в каждой задаче нужно передавать весь контекст (подробнейшее описание того, как работает программа). У меня вот была задача по разработке формы, которая будет работать в нескольких режимах как минимум на 40 устройствах с учетом их особенностей. Описание было на 50 страниц, готовили его 3 месяца, и описана там была не вся система, и все равно приходилось писать кастомный код под каждое устройство. Программист будет всегда цениться за то, что сможет по минимальному описанию (бизнес-сценарий) продумать все технические кейсы и внедрить фичу в любую систему, это экономит бизнесу кучу денег и времени.
Хотя и можно для простейших задач создавать текстовые описания типа "создай компонент модалки", но даже в этом случае получишь как в статье - неоптимизированный, неподходящий для встраивания в систему код, который нужно ревьюить и переделывать. Куда проще и быстрее самому написать. Так что в рабочих сценариях пока не вижу применения для ИИ, только для обучения.
Эту технологию очень легко испортить - и то, что я писал из поверхностного, встречалось в каждом проекте, где использовалась css-in-js. И отсутствие корректного управления пропами, и стилизация чилдренов через звездочку, и отсутствие автоформатирования, и непонятные класснеймы либо инлайновые стили, и раздутое дерево компонентов, и смешение компонентов и стилевых компонентов, и деградация перфоманса. Если можно сделать столько ошибок в технологии - то вряд ли ее можно рекомендовать. Если для настройки и создания требований требуется опытный в этом senior - то популяризацией заниматься не нужно, кто умеет приготовить и проконтролировать корректное использование на протяжении всего цикла жизни проекта - тот будет использовать. Но статьи на хабре часто берут на вооружение молодые специалисты, и пока они соберут все грабли - проект может зарыться в багах и низкой скорости разработки. А "готовить" css-in-js очень сложно, требуется постоянный контроль, с этим вы скорее всего согласитесь
Проблем намного больше, это просто верхушка айсберга - я написал комментарий в поддержку статьи, так как сам столкнулся с огромным количеством проблем от разных библиотек css-in-js и полностью разочаровался в этом подходе, который только через несколько лет начал подбираться по удобству к написанию стилей в отдельных файлах с препроцессором. И все мои коллеги согласны с этим, все без исключения вернулись к CSS modules - поэтому IMHO css-in-js может использоваться только теми, кто недостаточно с ним поработал. Часто я говорю сторонникам "через какое-то время вы со мной согласитесь", и это оправдывалось в ряде случаев. Я вас понимаю, сам был оптимистичен и использовал многие подходы из вшивания стилей в разметку.
В CSS Modules нет проблемы передачи пропов стилизации. Есть компоненты, есть стили, которые прикрепляются через className - это единственная точка соприкосновения стилей и компонентов. Нет возни с TS, нет лишних оберток и компонентов, нет лишних импортов, нет лишнего кода в бандле, нет дополнительной ответственности разработчика, нет дополнительного времени на реализацию.
Подсветка, автодополнение - да, сейчас решаются плагинами. Автоформатирование stylelint, проверка синтаксиса - их тоже уже подвезли? Если так, и для всех распространенных IDE + вариант через консольную команду для precommit и CI, то хорошо, этот пункт снимается.
Указав на пример styled(Button) вы проигнорировали пункт про omitProps - какие пропы должны передаваться в стили, а какие в компонент? А если в компоненте стоит { onClick, ...otherProps } = this.props, и вы забыли обернуть styled(Button) в omitProps(styled(Button), 'someStyleProp'), то будет ругань в TS, в консоли от неизвестного пропа для html + поломка гидрации SSR в ряде случаев. Очень много с этим сталкивался, под полсотни hotfix в master у меня из-за этого накопилось в тех проектах, которые использовали css-in-js.
Про извлечение в чанки с автосгенерированным именем тоже описал ряд консернов.
Зачем с этим всем бороться на пустом месте, когда альтернатива в виде CSS Modules лишена всех этих недостатков?
"Лично мне не нравятся повсеместные стрелочные функции и this" - странный аргумент для меня. Написание method = () => вместо method() и this сподвигли на то, чтобы выпустить новую утилиту, которая превращает функциональные компоненты Реакта в SolidJS-like? Но классы ведь придуманы для удобной организации кода. Чтобы не была функция из 5000 строк и 50 вложенных функций смешанного назначения, а были удобно организованные слои - хендлеры пользовательский событий, реакции, состояние, геттеры подготовленных данных, которые схлопываются IDE и гармонично могут использовать друг друга без заботы о hoisting, когда const a = 1 объявлена ниже, чем используется.
И в целом функциональные компоненты для меня очень неудобны как раз отсутствием this - в каждый хук надо передавать состояние, результат других хуков и при необходимости ссылки на них, в данной статье эти кейсы не показаны, но в реальности может быть myCustomHook(...10 params). В классах этой проблемы нет благодаря this и тому, что каждый метод имеет доступ ко всем другим методам, геттерам и состоянию.
Думаю, будущее все-таки за классами, и то что разработчики реакта придумали с раздутыми функциями с необходимостью ручного проброса одного в другое, скрытыми хранилищами и ручной заботой о равенстве по ссылкам уйдет в прошлое. Хотя afc решает часть проблем, остальные остаются.
Однозначно палец вверх за статью, хороший заход из песочницы, но перфоманс в широком смысле - это меньшая из зол css-in-js. Можно вполне жить и с увеличенным временем сборки, и с тормозами в интерфейсе, и замедленной работой IDE и TS за счет новых ts-файлов. И даже с разметкой таблицы, где в style в каждой колонке вшиты стили и при SSR размер html-страницы за счет этого вырастает в разы, а найти элемент в разметке инспектора по стилям и потом в проекте - отдельная форма извращения, в том числе если эти стили автоматом выносятся в классы с md5-like наименованием. А даже с фичей вынесения классов редко какой css-in-js движок делает достойную оптимизацию типа CSSO, и не все умеют в полифиллы по browserslist.
Недостатков в dev experience намного больше. Начиная от отсутствия поддержки подсветки синтаксиса и автоформатирования внутри js-строк, продираясь через тонну компонентов Button / StyledButton, по которым не поймешь - стиль это или компонент, потом пролезая через море оберток в инспекторе Components из React Dev Tools и постоянной работы с omitProps, чтобы этот стилизованный компонент прокидывал все что нужно в собственно целевой реакт-компонент и TS не ругался, приходишь в итоге к "> * {}" для стилизации children. И можно считать себя счастливчиком, если при этом всем не пришлось допиливать функционал, который есть в любом препроцессоре из коробки...
Мне сложно понять, кто может использовать эту технологию в production, но почему-то статьи на хабре в пользу css-in-js до сих пор появляются, хотя их уже мало кто комментирует - слишком много уже это все обсуждали.
У Asus большие проблемы с поставками. Мечтал весь год об Asus ExpertCenter PN64 , вышел вроде в июне, в продаже до августа - 0 предложений. Потом появились в ряде магазинов (Германия, Швейцария, Сингапур), но куда ни писал - везде отвечают "поставщик не прислал нам товар, в наличии нет". До декабря мучался пытался заказать, в итоге взял MOREFINE M600 R9-6900HX, который сразу доступен был после анонса и быстро пришел (пока не запускал, жду комплектующих). Вполне вероятно, что с модификацией PN64 на Raptor Lake будет похожая история, поэтому лучше с осторожностью относиться к этой модели
Сложно научить машину думать как человек и обладать его компетенциями. Вроде простой кейс для человека - открыть страницу, увидеть что ничего не поехало, попрокручивать. Для машины это проверить наличие тысяч элементов, их взаимоположения, в разных режимах адаптивности (несколько вариантов мобильных устройств, планшеты, десктоп), высчитать возможный скролл, проверить по Intersection Observer (которые нужно еще везде развесить), что элемент виден в определенном положении скролла. Нужны еще константные непротиворечивые идентификаторы, благодаря которым тест не сломается на середине. И это простейший кейс, который человеком проверяется за секунды, а кодом описать - как космолет запустить.
Вариант со скриншотами тоже имеет массу ограничений, хотя для машины сравнить 2 картинки и высчитать расхождения несложно. Что уж говорить о сложных кейсах и поведении юзера, которое почти нереально предсказать, и его условиях в виде медленного и нестабильного интернета. Ручных тестировщиков, на мой взгляд, заменить в ближайшей перспективе не получится, можно только немного убедиться, что в определенных идеальных кейсах код будет работать успешно.
Cypress, на мой взгляд, лучше подходит для интеграционных тестов - у него есть как режим прогона в открытом браузере, так и в headless режиме. Но это требует запуска проекта в отдельном процессе (либо докер-контейнере), на который уже заходит Cypress. Это усложняет настройку CI, но упрощает подготовку самих тестов - не нужно вызывать методы рендеринга в некий nodejs-DOM и надеяться, что в актуальных браузерах тоже будет работать, так как тест заходит на реальный запущенный сайт в реальном браузере.
С Кентом хотелось бы согласиться, и сложно не согласиться, что E2E это единственная осязаемая гарантия итоговой работоспособности, но найти компанию, которая потратит столько усилий для создания на каждый тест стабильных стендов со всей инфраструктурой бэка и базами с сэмпловыми данными в соответствии с текущей веткой каждого сервиса и структурой баз на определенный момент времени (либо версией, указанной вручную), мне пока не удалось. Особенно, если есть интеграции со внешними сервисами, ибо в каждом нужно сконфигурировать работу с данным тест-стендом. Были попытки на реальных стендах прогонять, создавая море новых юзеров и не завязываясь на стабильные сущности, но этим можно покрыть только функционал "котик отобразился" без конкретизации какой котик, в каком порядке, с какими характеристиками, какими действиями при клике и т.п., что надежности продукту не добавляет.
Я когда ни спрашиваю "хочет ли бизнес много некачественных фич", отвечают "хотим 30% усилий которые дают 70% результата". Эта сказка качует из ума одного менеджера к другому, дает им отчитаться про "мы внедрили вот это по плану 1 неделя вместо 1 месяца, супер-топ команда и метод управления". В реальности получается костыльное минимально рабочее решение + 70% техдолга, который в геометрической прогрессии растет и сначала тормозит дальнейшую разработку, а в скором времени - блокирует. Факт, что то что таким образом написано за год надо дорабатывать еще 2 года все гонят прочь, разработчики не могут разобраться в той каше, которую из себя представляет продукт и уходят, новые нанятые какое-то время мучаются и смиряются до тех пор, пока история не повторится, внедрение фич идет медленно, менеджеры нанимают еще разработчиков и затраты растут как снежный ком, денег не хватает, клиенты и инвесторы в ярости, компания рушится.
Стандартный кейс, который встречал практически везде, где бизнес гонится за скоростью и играет "в быструю", а не "в долгую". Ситуация особенно усугубляется, если используются велосипедные решения и их разработчики становятся ключевыми, тогда скорый исход проекта в небытие еще ускорится, сколько бы строк в таблице ни выводил этот фреймворк. Исходя из этой специфики я бы все равно придерживался популярных решений (React, Vue, Angular) - так хотя бы можно отсрочить кризис в компании. Но решить его может только сам бизнес, кардинально изменив модель требований и ожиданий.
Рынок подстраивается под популярные технологии, это нормально для всех отраслей - раньше нужны были кто работал лопатой, теперь экскаватором. Много курсов Реакта и Вью выпускают много потенциальных разработчиков. Есть временной лаг между этапами спрос-предложение-"предложение с опытом работы YYY", но не критичный на мой взгляд, и доносит до бизнеса идею что сотрудников нужно в том числе выращивать самостоятельно.
Поддерживаю. Архитектуры и проекты в целом в подавляющем большинстве одинаковые с небольшой в масштабах приложения спецификой (для того же получения данных - REST, RPC, Socket, binary, GraphQL), которая разруливается адаптерами. Целые массивные слои (роутинг, сборка, валидация, кодогенерация, темизация, локализация, механизмы SSR, BFF) с незначительными изменениями таскаю из конторы в контору с крайне различающимся бизнес-направлением (от банков до бирж), если сделать их достаточно гибкими и фреймворконезависимыми.
И по поводу основной проблемы бизнеса тоже соглашусь, на мой взгляд это "все надо очень быстро", которая исходит из самой сути предпринимательства - вложения денег ради получения денег. Это приводит к требованиям использовать широко распространенный фреймворк, готовые библиотеки и взаимозаменяемых сотрудников, которых легко найти на рынке. И рождает требование "технари в первую очередь должны думать о бизнесе (читай - быстром росте количества фичей), а потом о своих идеалах, скорости приложений, стабильности, архитектурной согласованности, поддерживаемости". Мне это тоже доставляет личную боль как творческому человеку, и боль за результаты своего труда, потому что высокая скорость разработки приводит к формированию легаси и техдолга, которые за пару лет могут превратить проект в неподдерживаемый и нестабильный. Но с этим приходится мириться, вкладывая усилия в гибкость архитектуры, чтобы в будущем довольно просто можно было сменить одни части на другие и достаточно изолированно отрефакторить.
Мне казалось, что чтобы вырасти из миддла в синьоры нужны паттерны. Читал много книг, делал в разных паттернах решение одной и той же задачи, сравнивал перфоманс, масштрабируемость, DX и т.п. Но на протяжении последующих лет пригодились только в обсуждениях в чатах + для общего развития мышления. В реальности нужно совсем другое - абстракция сложности и понятность кода. Первое подразумевает, что можно в выделенной библиотеке писать так, чтобы тебе было понятно, а в коде проекта - чтобы было понятно джуну. Если проект долгоживущий - добавляешь к библиотекам документацию, чем руководствовался при выборе таких подходов, чтобы пришедшие на смену архитекторы могли дорабатывать либо переписывать по своему усмотрению, но код проекта оставался бы таким же простым.
Поэтому все же я думаю, что спрашивать про паттерны не надо ни джунов, ни синьоров, но миддлов погонять можно - это покажет кругозор
Спасибо за статью, прямо с языка все сняли. Сколько ни работал в небольших компаниях и стартапах - история везде одинаковая. Совмещение нескольких должностей, переработки, обещание золотых гор (вам повезло по поводу реальных выплат премий - на моей практике это исключительный случай), абсолютно нереалистичные ожидания с мотивацией "нам надо бежать еще быстрее, чтобы всех перегнать", малое внимание к качеству и стабильности продукта, "мнение начальства непререкаемо", нехватка специалистов, часто - отсутствие отпусков, высокая текучка. Это характерно не только для российских контор - в зарубежных часто не лучше, но как правило более демократично (более горизонтальные структуры).
Я тоже из-за внутреннего чувства ответственности и на ранних стадиях из-за обещаний "золотых гор" выжимался в каждой из компаний, да и сейчас продолжаю в точно такой же ситуации. Но внутренних ресурсов все меньше, а раздражения все больше, отчего иногда становлюсь "токсичным". Все еще надеюсь, что найду нормальную компанию (в крупных конторах действительно было намного спокойнее).
Вариант лучше, без дополнительных классов/data-theme/отдельных параметров --color-dark/--color-light, за которыми еще и нужно следить для избежания коллизий имен - это CSS variables записывать напрямую в <html style="--color-primary=#ccc"> . При смене темы соответственно менять их значения там же. И только для исключительных случаев (разная логика в разных темах) пригодится глобальный идентификатор в виде класса или data-theme. Таким образом значительно уменьшится количество кода и не нужно в стилях прописывать дополнительные служебные переменные
Надо упомянуть, что схема не будет работать с SSR - кука будет прикреплена к домену jsonplaceholder.typicode.com , а не домену фронта, так что node-сервер не сможет ее получить и зафорвардить в апи. Также и из локалстораджа он не получит токен. То есть для SSR юзер всегда будет неавторизован. Конечно, для авторизованных зон SSR зачастую избыточен, но ряд сайтов (маркетплейсы, к примеру) от этого пострадают, хотя и не слишком сильно.
На Хабре обсуждалось не раз предложение "сделать единое AST для TS, ESLint, Webpack и других сборщиков, переиспользовать в IDE", вроде вы тоже участвовали в обсуждениях. Но каждый раз приходим к тому, что есть разные лицензии, корпоративные политики (TS), ограничения операционных систем, разность механик работы разных инструментов. Я тоже хотел бы видеть "универсальный процесс, генерирующий универсальное дерево с адаптером ко всем языкам программирования", это был бы, наверное, лучший вклад в экосистему разработки за десятилетия, но остается только мечтать...
Только начал всю эту канитель, вроде как можно не 8 лет для подтверждения квалификации, а 6 + описание проектов на полкниги. Надеюсь на удачу, что 70-75 баллов каким-то образом стрельнут, также думаю проработать вариант с удаленной работой на австралийскую контору - может тоже зачтется. Спасибо за опыт, креплюсь)
Самое главное забыли - в ряде случаев (когда они появились - практически во всех браузерах так было) у стрелочной функции нет name, `const fn = () => false`, fn.name undefined|''. То есть в стек-трейсе будет anonymous, и если код минифицирован, найти причину бага очень сложно. Но в современных браузерах name назначается по имени константы. Это все еще приходится держать в голове. В определенных случаях и современные браузеры не назначат - `const fn = (() => () => { return false })()`.
Также стрелочные функции, назначенные как константы, нельзя использовать выше их объявления, в отличие от именованных. То есть в ряде случаев придется жонглировать местами объявления.
Еще натыкался на то, что стрелочные методы классов в определенных версиях транспиляторов не декорируются, так как на выходе код совершенно другой, чем у нестрелочного метода.
Фича в целом отличная, но об ограничениях нужно помнить
Это рекламная статья "для галочки", что "популяризируют Сбер на Хабре", только тег реклама не указали. Тут не с кем обсуждать архитектуру.
Чтобы написать достаточно полные описания, по которым ИИ сможет сгенерировать достаточно полноценный код, труда надо намного больше, потому что в каждой задаче нужно передавать весь контекст (подробнейшее описание того, как работает программа). У меня вот была задача по разработке формы, которая будет работать в нескольких режимах как минимум на 40 устройствах с учетом их особенностей. Описание было на 50 страниц, готовили его 3 месяца, и описана там была не вся система, и все равно приходилось писать кастомный код под каждое устройство. Программист будет всегда цениться за то, что сможет по минимальному описанию (бизнес-сценарий) продумать все технические кейсы и внедрить фичу в любую систему, это экономит бизнесу кучу денег и времени.
Хотя и можно для простейших задач создавать текстовые описания типа "создай компонент модалки", но даже в этом случае получишь как в статье - неоптимизированный, неподходящий для встраивания в систему код, который нужно ревьюить и переделывать. Куда проще и быстрее самому написать. Так что в рабочих сценариях пока не вижу применения для ИИ, только для обучения.
Эту технологию очень легко испортить - и то, что я писал из поверхностного, встречалось в каждом проекте, где использовалась css-in-js. И отсутствие корректного управления пропами, и стилизация чилдренов через звездочку, и отсутствие автоформатирования, и непонятные класснеймы либо инлайновые стили, и раздутое дерево компонентов, и смешение компонентов и стилевых компонентов, и деградация перфоманса. Если можно сделать столько ошибок в технологии - то вряд ли ее можно рекомендовать. Если для настройки и создания требований требуется опытный в этом senior - то популяризацией заниматься не нужно, кто умеет приготовить и проконтролировать корректное использование на протяжении всего цикла жизни проекта - тот будет использовать. Но статьи на хабре часто берут на вооружение молодые специалисты, и пока они соберут все грабли - проект может зарыться в багах и низкой скорости разработки. А "готовить" css-in-js очень сложно, требуется постоянный контроль, с этим вы скорее всего согласитесь
Проблем намного больше, это просто верхушка айсберга - я написал комментарий в поддержку статьи, так как сам столкнулся с огромным количеством проблем от разных библиотек css-in-js и полностью разочаровался в этом подходе, который только через несколько лет начал подбираться по удобству к написанию стилей в отдельных файлах с препроцессором. И все мои коллеги согласны с этим, все без исключения вернулись к CSS modules - поэтому IMHO css-in-js может использоваться только теми, кто недостаточно с ним поработал. Часто я говорю сторонникам "через какое-то время вы со мной согласитесь", и это оправдывалось в ряде случаев. Я вас понимаю, сам был оптимистичен и использовал многие подходы из вшивания стилей в разметку.
В CSS Modules нет проблемы передачи пропов стилизации. Есть компоненты, есть стили, которые прикрепляются через className - это единственная точка соприкосновения стилей и компонентов. Нет возни с TS, нет лишних оберток и компонентов, нет лишних импортов, нет лишнего кода в бандле, нет дополнительной ответственности разработчика, нет дополнительного времени на реализацию.
Подсветка, автодополнение - да, сейчас решаются плагинами. Автоформатирование stylelint, проверка синтаксиса - их тоже уже подвезли? Если так, и для всех распространенных IDE + вариант через консольную команду для precommit и CI, то хорошо, этот пункт снимается.
Указав на пример styled(Button) вы проигнорировали пункт про omitProps - какие пропы должны передаваться в стили, а какие в компонент? А если в компоненте стоит { onClick, ...otherProps } = this.props, и вы забыли обернуть styled(Button) в omitProps(styled(Button), 'someStyleProp'), то будет ругань в TS, в консоли от неизвестного пропа для html + поломка гидрации SSR в ряде случаев. Очень много с этим сталкивался, под полсотни hotfix в master у меня из-за этого накопилось в тех проектах, которые использовали css-in-js.
Про извлечение в чанки с автосгенерированным именем тоже описал ряд консернов.
Зачем с этим всем бороться на пустом месте, когда альтернатива в виде CSS Modules лишена всех этих недостатков?
"Лично мне не нравятся повсеместные стрелочные функции и this" - странный аргумент для меня. Написание method = () => вместо method() и this сподвигли на то, чтобы выпустить новую утилиту, которая превращает функциональные компоненты Реакта в SolidJS-like? Но классы ведь придуманы для удобной организации кода. Чтобы не была функция из 5000 строк и 50 вложенных функций смешанного назначения, а были удобно организованные слои - хендлеры пользовательский событий, реакции, состояние, геттеры подготовленных данных, которые схлопываются IDE и гармонично могут использовать друг друга без заботы о hoisting, когда const a = 1 объявлена ниже, чем используется.
И в целом функциональные компоненты для меня очень неудобны как раз отсутствием this - в каждый хук надо передавать состояние, результат других хуков и при необходимости ссылки на них, в данной статье эти кейсы не показаны, но в реальности может быть myCustomHook(...10 params). В классах этой проблемы нет благодаря this и тому, что каждый метод имеет доступ ко всем другим методам, геттерам и состоянию.
Думаю, будущее все-таки за классами, и то что разработчики реакта придумали с раздутыми функциями с необходимостью ручного проброса одного в другое, скрытыми хранилищами и ручной заботой о равенстве по ссылкам уйдет в прошлое. Хотя afc решает часть проблем, остальные остаются.
Однозначно палец вверх за статью, хороший заход из песочницы, но перфоманс в широком смысле - это меньшая из зол css-in-js. Можно вполне жить и с увеличенным временем сборки, и с тормозами в интерфейсе, и замедленной работой IDE и TS за счет новых ts-файлов. И даже с разметкой таблицы, где в style в каждой колонке вшиты стили и при SSR размер html-страницы за счет этого вырастает в разы, а найти элемент в разметке инспектора по стилям и потом в проекте - отдельная форма извращения, в том числе если эти стили автоматом выносятся в классы с md5-like наименованием. А даже с фичей вынесения классов редко какой css-in-js движок делает достойную оптимизацию типа CSSO, и не все умеют в полифиллы по browserslist.
Недостатков в dev experience намного больше. Начиная от отсутствия поддержки подсветки синтаксиса и автоформатирования внутри js-строк, продираясь через тонну компонентов Button / StyledButton, по которым не поймешь - стиль это или компонент, потом пролезая через море оберток в инспекторе Components из React Dev Tools и постоянной работы с omitProps, чтобы этот стилизованный компонент прокидывал все что нужно в собственно целевой реакт-компонент и TS не ругался, приходишь в итоге к "> * {}" для стилизации children. И можно считать себя счастливчиком, если при этом всем не пришлось допиливать функционал, который есть в любом препроцессоре из коробки...
Мне сложно понять, кто может использовать эту технологию в production, но почему-то статьи на хабре в пользу css-in-js до сих пор появляются, хотя их уже мало кто комментирует - слишком много уже это все обсуждали.
У Asus большие проблемы с поставками. Мечтал весь год об Asus ExpertCenter PN64 , вышел вроде в июне, в продаже до августа - 0 предложений. Потом появились в ряде магазинов (Германия, Швейцария, Сингапур), но куда ни писал - везде отвечают "поставщик не прислал нам товар, в наличии нет". До декабря мучался пытался заказать, в итоге взял MOREFINE M600 R9-6900HX, который сразу доступен был после анонса и быстро пришел (пока не запускал, жду комплектующих). Вполне вероятно, что с модификацией PN64 на Raptor Lake будет похожая история, поэтому лучше с осторожностью относиться к этой модели
Сложно научить машину думать как человек и обладать его компетенциями. Вроде простой кейс для человека - открыть страницу, увидеть что ничего не поехало, попрокручивать. Для машины это проверить наличие тысяч элементов, их взаимоположения, в разных режимах адаптивности (несколько вариантов мобильных устройств, планшеты, десктоп), высчитать возможный скролл, проверить по Intersection Observer (которые нужно еще везде развесить), что элемент виден в определенном положении скролла. Нужны еще константные непротиворечивые идентификаторы, благодаря которым тест не сломается на середине. И это простейший кейс, который человеком проверяется за секунды, а кодом описать - как космолет запустить.
Вариант со скриншотами тоже имеет массу ограничений, хотя для машины сравнить 2 картинки и высчитать расхождения несложно. Что уж говорить о сложных кейсах и поведении юзера, которое почти нереально предсказать, и его условиях в виде медленного и нестабильного интернета. Ручных тестировщиков, на мой взгляд, заменить в ближайшей перспективе не получится, можно только немного убедиться, что в определенных идеальных кейсах код будет работать успешно.
Cypress, на мой взгляд, лучше подходит для интеграционных тестов - у него есть как режим прогона в открытом браузере, так и в headless режиме. Но это требует запуска проекта в отдельном процессе (либо докер-контейнере), на который уже заходит Cypress. Это усложняет настройку CI, но упрощает подготовку самих тестов - не нужно вызывать методы рендеринга в некий nodejs-DOM и надеяться, что в актуальных браузерах тоже будет работать, так как тест заходит на реальный запущенный сайт в реальном браузере.
С Кентом хотелось бы согласиться, и сложно не согласиться, что E2E это единственная осязаемая гарантия итоговой работоспособности, но найти компанию, которая потратит столько усилий для создания на каждый тест стабильных стендов со всей инфраструктурой бэка и базами с сэмпловыми данными в соответствии с текущей веткой каждого сервиса и структурой баз на определенный момент времени (либо версией, указанной вручную), мне пока не удалось. Особенно, если есть интеграции со внешними сервисами, ибо в каждом нужно сконфигурировать работу с данным тест-стендом. Были попытки на реальных стендах прогонять, создавая море новых юзеров и не завязываясь на стабильные сущности, но этим можно покрыть только функционал "котик отобразился" без конкретизации какой котик, в каком порядке, с какими характеристиками, какими действиями при клике и т.п., что надежности продукту не добавляет.
Я когда ни спрашиваю "хочет ли бизнес много некачественных фич", отвечают "хотим 30% усилий которые дают 70% результата". Эта сказка качует из ума одного менеджера к другому, дает им отчитаться про "мы внедрили вот это по плану 1 неделя вместо 1 месяца, супер-топ команда и метод управления". В реальности получается костыльное минимально рабочее решение + 70% техдолга, который в геометрической прогрессии растет и сначала тормозит дальнейшую разработку, а в скором времени - блокирует. Факт, что то что таким образом написано за год надо дорабатывать еще 2 года все гонят прочь, разработчики не могут разобраться в той каше, которую из себя представляет продукт и уходят, новые нанятые какое-то время мучаются и смиряются до тех пор, пока история не повторится, внедрение фич идет медленно, менеджеры нанимают еще разработчиков и затраты растут как снежный ком, денег не хватает, клиенты и инвесторы в ярости, компания рушится.
Стандартный кейс, который встречал практически везде, где бизнес гонится за скоростью и играет "в быструю", а не "в долгую". Ситуация особенно усугубляется, если используются велосипедные решения и их разработчики становятся ключевыми, тогда скорый исход проекта в небытие еще ускорится, сколько бы строк в таблице ни выводил этот фреймворк. Исходя из этой специфики я бы все равно придерживался популярных решений (React, Vue, Angular) - так хотя бы можно отсрочить кризис в компании. Но решить его может только сам бизнес, кардинально изменив модель требований и ожиданий.
Рынок подстраивается под популярные технологии, это нормально для всех отраслей - раньше нужны были кто работал лопатой, теперь экскаватором. Много курсов Реакта и Вью выпускают много потенциальных разработчиков. Есть временной лаг между этапами спрос-предложение-"предложение с опытом работы YYY", но не критичный на мой взгляд, и доносит до бизнеса идею что сотрудников нужно в том числе выращивать самостоятельно.
Поддерживаю. Архитектуры и проекты в целом в подавляющем большинстве одинаковые с небольшой в масштабах приложения спецификой (для того же получения данных - REST, RPC, Socket, binary, GraphQL), которая разруливается адаптерами. Целые массивные слои (роутинг, сборка, валидация, кодогенерация, темизация, локализация, механизмы SSR, BFF) с незначительными изменениями таскаю из конторы в контору с крайне различающимся бизнес-направлением (от банков до бирж), если сделать их достаточно гибкими и фреймворконезависимыми.
И по поводу основной проблемы бизнеса тоже соглашусь, на мой взгляд это "все надо очень быстро", которая исходит из самой сути предпринимательства - вложения денег ради получения денег. Это приводит к требованиям использовать широко распространенный фреймворк, готовые библиотеки и взаимозаменяемых сотрудников, которых легко найти на рынке. И рождает требование "технари в первую очередь должны думать о бизнесе (читай - быстром росте количества фичей), а потом о своих идеалах, скорости приложений, стабильности, архитектурной согласованности, поддерживаемости". Мне это тоже доставляет личную боль как творческому человеку, и боль за результаты своего труда, потому что высокая скорость разработки приводит к формированию легаси и техдолга, которые за пару лет могут превратить проект в неподдерживаемый и нестабильный. Но с этим приходится мириться, вкладывая усилия в гибкость архитектуры, чтобы в будущем довольно просто можно было сменить одни части на другие и достаточно изолированно отрефакторить.