Не совсем понял про менеджеров и карточки)

Нет времени, заняты, много комманд. Это административный вопрос. Просто относится нужно также как и к любой другой задаче. Каким образом спустить эту инфу к лидам комманд - сообщить через чат всем, или создать задачу в таск-трекере.. понятное дело зависит от дисциплины, количества комманд, етс.

Также не совсем понял почему именно и что свалится в процессе CI. Вы ш уже административно поделили бизнес на команды. Они ж не просто так названы - команды. Это отдельные единицы со своим внутренним миром, со своими тараканами. Что-то обобщать - верный путь к переопределениям, иф-ам и т.д.

Тут надо посчитать, что дешевле

Именно. Уже ш подсчитали в умных книжках. Если процесс частый и регулярный - делаем автоматизацию. Если раз в пятилетку - нет (копи-паст выгоднее). На самом деле ноги ростут из подсознательного желания чтоб всё и вся соответствовало принципу DRY, и подсознательного желания программиста всё упорядочить и усложнить, даже в жизни..)

 многократное редактирование всех проектов может быть трудозатратным и неэффективным.

Почему многократное? Один раз сообщить всем - "парни, с понедельника у нас новое правило. Обновите свои конфиги, плзз". Разве это "трудозатратно и неэффективно" по сравнению с

и его последующая публикация в репозитории пакетов

и эти изменения автоматически применятся ко всем проектам

Точно автоматически? Или всё-же нужно будет совершить три действия - обновить общий конфиг; сообщить всем что конфиг обновился; и потом командам подтянуть этот конфиг.

Вместо того чтобы править конфигурации в каждом проекте, вы вносите изменения только в Shareable config и публикуете его. Это экономит время и уменьшает затраты на обслуживание.

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

и вы сделаете дополнительную автоматизацию

Вы сделаете high cohesion. Автоматизировать нужно не всё подряд, а то, что регулярно и часто повторяется.

Кнопкам без текста, с свг-шкой внутри добавляю только атрибут title. aria-label обязателен в таком случае?

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

каждый дубль элемента — модальное окно, кнопку, инпут — приходилось поддерживать отдельно, на это тратились ресурсы.

Неужели много "ресурсов" тратилось?. Дизайнер решил поменять бордер-радиус у кнопки на 4рх. Создал таску, оповестил всех в общем чате, етс - каждая команда взяла и сделала это у себя в проекте. Это просто, быстро, независимо, понятно и прогнозируемо. Ответственность не размывается. Нет high cohesion. Потом, опа, дизайнер решил в одном проекте чтоб кнопки были красные, а в другом синие.. команды реализовали это отдельно по проектам, не будет мук совести при добавлении if-а в общую библиотеку. Также такой подход легко переживает период смены главных дизайнеров (как правило раз в пару лет) и очередных глобальных редизайнов.

Мой поинт в том, что копи-пастить ui между проектами можно, это меньшее зло, если зло вообще.

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

Из минусов лично для меня выделил следующие:

Дополню. Разработчик там один китаец, которого может збить автобус. И насколько помню - он основной разработчик vue.. соответственно приоритет при решении проблем будет отдавать больше vue чем реакту, чтобы продвигать свою библиотеку.

TailwindNotation.vue

какой-то mol/svelte подобный кашмарный синтаксис

Земля пухом тому кто на проде это говно увидит. Челу буквально придётся учить новый синтаксис, вместо знакомого css и выжигать о него глаза.

как вариант удалять эту г*нину постепенно\по-компонентно и заменять на свои нормальные стили. Container-queries также помогут в этом.

Всю жизнь интересуют такие вопросы:

• Есть десктоп мониитор с 3840*2160 родных пикселей. Юзер не трогал масштабирование ни в ос, ни в браузере, ему нравится всё мелкое допустим. Этому клиенту шлём картинку 3840*2160. Правильно?

• Есть телефон, ретина-дисплей с родным разрешением также 3840*2160px. Но встроенное масштабирование допустим 1:4 - т.е. 960*540 виртуальных css-пикселей. Вопрос - какую картинку слать этому клиенту? - 3840*2160 (у него ж ретина, нельзя обделять), или слать мыло 960*540 (у него ж мобильный, с дорогим и плохим интернетом, и он в метро)?

• Если принять, что у целевой аудитории только ретина-мобильные, и хороший бесплатный wifi - можно ли слать просто одну картинку 3840*2160 на всех клиентов, не заморачиваясь с picture/src-set и прочими intersectionObserver?)

Это была первая пк-игра-гонка в жизни. В компьютерном клубе.
Недавно как раз установил - аж мурашки по коже пошли. Интро, дизайн-меню, музыка - божественны.

Также установил ещё одну игру детства - grand prix 4 - нереальные флешбеки споймал. Тоже шедевральные дизайн-меню и музыка на фоне.

• На беке будет бизнес-логика - "не выдавать кредит лицам младше 18 лет" (т.е. тут по настоящему нужно проверять, вдруг запросы курлом приходят).

• На фронте будет ui-правило - "не показывать следующий шаг формы, если на первом шаге поле возраст меньше 18 лет" (т.е. тут сугубо фронтовая история, именно этого фронта, в мобильном приложении всё может быть оформленно по другому).
  
  UI-правилами на каждом конкретном фронте - могут крутить и вертеть как угодно в зависимости от ux! Мой поинт в том, что фронт может меняться быстро и часто, и неправильно говорить что во фронте есть бизнес-логика (несмотря на то что иногда есть дублирование правил валидации как на клиенте так и на беке - но это разные валидации).. просто кому-то хочется добавить важности обычной "вьюхе" в терминах MVC.

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

Если речь про мутиции, то есть метод mutateAsync, который возвращает Promise и работает с async/await.

Можете пожалуйста подсказать как закодировать такую логику:

- по сабмиту получаем данные из формы
- делаем три параллельных запроса, в каждом из которых свои данные формы
- по результату второго запроса - делаем или не делаем четвёртый запрос, в котором используем ответ первого запроса.
- если четвёртый запрос ок - показываем успех с данными из этого запроса-4

На обычноим js это получается просто и понятно:

const submitHandler = async (formData) => {
  const responses = await Promise.all([
    service1.fetchData(formData.fieldValue1),
    service2.fetchData(formData.fieldValue2),
    service3.fetchData(formData.fieldValue3),
  ]);

  if (responses[1].isExistSomeData) {
    const data = await service4.fetchData(responses[0]);
    service5.showSuccess(data);  
  } else {
    service5.showFailure();  
  }
};

Как это будет выглядеть в jsx-компоненте с помощью react-query? У меня получается ужасно.)

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

Какой-бы крутой и "полезный" не был бы RxJs - с точки зрения бизнеса его лучше запретить использовать. Любую, самую галюцагенную, задачу лучше запрограммировать чуть большим количеством кода, но зато более выразительным и поддерживаемым способом. kiss

Всё никак не пойму популярность этих reаct-query\swr. Какие-то слишком замудрённые, а рекламируемый профит так себе. Честно пробовал прикрутить к домашнему проекту, плюнул и отказался через час:

- обалдел когда увидел апи и кучу флажков, напрмиер, isFetching, isLoading, isIdle и куча тонкостей какой когда лучше использовать.

- обалдел когда попытался по сабмиту сделать три параллельных запроса, и потом по результату например второго из них нужно сделать\или не сделать четвёртый запрос. Оно меня отправляет в dependent-queries. Вместо async\await сверху вниз - код становится какой-то ужасный.. сплошные use.. use..

- не получается делать запросы вне jsx-компонента без use (у меня проект на mobx, поэтому вся логика в сторах, а реакт просто шаблонизатор). Оно конечно предлагает использовать queryClient.fetchQuery,но как я понял теряются многие рекламируемые плюшки.

Может всё-таки мало времени уделил.

Показать третий шаг формы, вместо второго, на основе поля ввода в первом шаге;
динамическая смена валидации полей на основе других полей и тд. - это всё логика UI конкретно этого клиента (фронта).

Настоящие бизнес-правила (источник истины) - находятся вне браузера, на бекенде, в схеме бд если угодно. Конечно же если мы говорим про распределённые системы, а не бекенд-лесс-браузерные инструменты (игры, редакторы, и т.д.).

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

• отреагировать на действия юзера по каким-то ui-правилам

• отправить этот результат действия на бек

• там произойдёт настоящее бизнес-правило и валидация

• отправить результат назад на фронт, отреагировать на это по каким-то ui-правилам
  

О, моя любимая тема) Всё ниже относится конечно же к закрытым проектам.

Вот бывает, смотришь ты историю коммитов проекта — и всё, казалось бы, хорошо и понятно, но вдруг натыкаешься на такое:

зачем туда смотреть? чтобы что?)

Особенно страшно видеть подобное в исполнении опытных разработчиков.

Может потому что "чистая история коммитов" никому на самом деле не нужна и ни на что не влияет?, и это просто какая-то религия.

в случае неполадок будет легче откатиться

используйте гит-тэги.

• Если нужна история проекта - читайте релиз-ноутсы написанные по-человечески для людей от тех-райтеров, вместо чтения истории срезов состояний кодовой базы от уходящих-приходящих но-нейм разработчиков.

• Новый разработчик в команде может глянуть на историю чисто ради оценки интенсивности разработки, ну и принципов именования коммитов. А так, вникай в предметную область, изучай кодовую базу, общайся(!) с коммандой, проходи онбординг, делай таски, оставляй после себя код лучше чем был.

• Гит и коммиты - это как источник истины\база\хранилище\блокчейн если угодно, а коммиты - типа миграций что-ли. Но точно уж не для чтения глазами истории проекта или "коммуникаций"

• Ах, удобно вырезать\вставить\черри-пикнуть какой-то красивый понятный атомарный коммит. Обычно это делается в рамках одного разработчика, в рамках одной фичи, в рамках небольшого промежутка времени, в общем в рамках одного понятного контекста. Никто не будет перемещать коммиты годичной давности.

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

• О, гит-коммиты можно привязывать к таск-треккеру. Типа удобно посмотреть начальную таску в одну строчку, которая три раза успела эволюционировать в процессе разработки. А если этот трекер поменяется. High cohesion или как-там правильно.

• Пишем юнит-тесты на бизнес логику

Во фронте почти не бывает бизнес-логики. Разве сам фронт и является продуктом - игра, онлайн-фотошоп, етс.

засучить рукава и начать прокликивать UI вручную

Наиболее оптимальный способ для бизнеса, и как ни странно для DX программиста (чтоб не выгорел от бесполезности бытия).

На месте руководителя - я бы запретил юнит-тесты на фронте, и нанял бы пару qa-мануальщиков на этапе активной разработки.

После оживления проекта, т.е. выкатки в прод и хоть какой-то генерации прибыли - добавил бы пару синьйоров на e2e и интеграционные тесты. С покрытием только багов, которые реально встретились в проде.

Юнит-тесты на фронте - прожигание ресурсов как человеческих, так и машинных. UI может меняться слишком быстро, чтобы писать на него тесты. Только если ваш продукт и есть сам UI - тогда ок, можно даже тестирование скриншотами добавить.

выстраивания четких границ между логикой и UI

Делать религию и городить абстракции между "логикой" и UI внутри фронта - также оверхед. Фронт - это всего-лишь view-слой всего MVC-приложения. Этот слой может меняться быстро и часто. Настоящая бизнес-логика\транзакции вот это всё - вне браузера. Внутри фронта - может быть сколько угодно сложная ui-ая логика, но это всего-лишь view-слой системы вцелом.

Iframe
Что касается недостатков, то главный из них — взаимодействие с поисковыми роботами.

Почему это недостаток? Зачем индексация и поисковые роботы в монстре-приложении:

крофронтенд, архитектурный подход, где независимые приложения собраны в одно комплексное приложение, 

которое будет за авторизацией