Паттерны верстки. Как объединить верстальщиков и дизайнеров

"поплывет" вся верстка

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

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

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

Для всего, что не должно зависеть от размера шрифта, не нужно использовать единицы, которые зависят от размера шрифта.

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

Паттерны верстки. Как объединить верстальщиков и дизайнеров

Не задавать высоту элементам (input button и тд) с помощью padding. Дизайнер задает конкретные параметры элемента в пикселях, поэтому изменение количества строк или внутреннего контента  повлияет на исходные размеры. Поэтому height у элементов задаем в пикселях

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

Лучше использовать пиксели в верстке, а не другие единицы измерения. Дизайн изначально создан в пикселях, поэтому не стоит вмешиваться в исходные параметры.

Еще как стоит. В бытность мою работы на фрилансе и галере веб-студии мне приходили макеты только для десктопа, при необходимости самому допиливать мобилку. Даже если и есть мобильные макеты, вы все-равно предлагаете отказаться от rem/em/%?

Получается, что:
1) Вместо установки rem на боди и пропорциональному уменьшению/увеличению его на мобилке, я должен буду руками ходить все исправлять?
2) Я не учитываю работу клиентского устройства под разного рода масштабированием

А масштабирование - это элемент доступности, вы предлагаете делать интерфейсы недоступными, просто потому что дизайнер прав? А если он не прав?

Данная статья поможет улучшить взаимодействие между дизайнерами и верстальщиками для минимизации ошибок и повышения продуктивности работы.

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

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

Почему стоит избегать? Опять же, тот же бутстрап позволяет атомарно пересобрать свою сетку просто импортируя к себе нужные scss файлы и дальше вот те примеры по изобретению велосипеда не нужны от слова совсем.
Например, откопал такие участки кода в своих проектах +-3 лет давности :

@import 'node_modules/bootstrap/scss/bootstrap-reboot.scss';
@import 'node_modules/bootstrap/scss/bootstrap-grid.scss';
@import 'node_modules/bootstrap/scss/utilities/_sizing';

/* Vars:
   ========================================================================== */

// Font
$mainFont: 'HelveticaNeue', 'Helvetica', 'Arial', sans-serif;
$mainFontColor: #101010;

//desktops
$large_desktop: 1440px;
$small_desktop: 1200px;
//tablets
$large_tablet: 992px;
$small_tablet: 768px;
//phones
$large_mobile: 576px;
$small_mobile: 460px;
//core font
$mainFontSize: 16px; //16px
$mainFontWeight: 400;
$mainLineHeight: 150%; //24x or 1.25rem
$boxHeight: $mainLineHeight;

//bootstrap sizing
$grid-gutter-width: 40px;
$grid-columns: 10;

$grid-breakpoints: (
  xs: 0,
  sm: $large_mobile,
  md: $small_tablet,
  lg: $large_tablet,
  xl: $small_desktop,
  xxl: $large_desktop,
);

$container-max-widths: (
  sm: 540px + $grid-gutter-width,
  md: 720px + $grid-gutter-width,
  lg: 960px + $grid-gutter-width,
  xl: 1170px + $grid-gutter-width,
  xxl: 1320px + $grid-gutter-width,
);

$gutter: $grid-gutter-width / 2;

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

Как подружить Git с приложением на Webpack+React

Можно пойти еще дальше и принудительно обновлять ветки, если локальный мастер отстает от ремоута :)

Мой опыт с Webpack 5 Module Federation

Ну и нет совместимости у федерализации с остальными сборщиками. Что привязывает консьюмеров к вебпаку.

а должна быть? Сборщик запилил такую вещь и логично, что завязывает на себя, чтобы пополнить комьюнити. Почему это не делают другие - вопрос. Хотя, судя по настроениям - не вопрос, ведь большинству либо страшно браться, либо "фу-фу, нафиг надо" .
Для сборки приложенек - вебпак, для сборки либ - роллап. Для меня ну вот вообще не проблема привязки к сборщику. Можно, конечно, приплести сюда snowpack, vite и все остальное, но для меня скорости стало достаточно, отказавшись от babel в пользу esbuild, а если надо будет собрать все лучшее - там где-то еще должен жить gulp, можно велосипед из сборщиков вокруг него построить, только зачем?

дык, при потреблении федерализации откуда типы брать?

я уже выше писал, что из коммон либы я в своем случае складывал. Неудобно, но не смертельно, либо подцепить кастомную types в tsconfig (что, видимо, вы и сделали).

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

Лежат точно так же в объекте, но не глобальном, если не указывать scope default. Каждый микрофронт может искать в отдельном скопе себе зависимости и выбрасывать туда, если нет зависимостей

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

Мой опыт с Webpack 5 Module Federation

К сожалению, такое случается :)

Когда заказчик узнал, что от MVP ничего не осталось, его удивлению не было предела :)

Мой опыт с Webpack 5 Module Federation

Нет, просто в хост приложении загружается uikit и шарится в микрофронт. Сответственно, инжектятся стили с хешами версии ядра.
В микрофронте приложении uikit потребляется из хоста, но если версия будет, например, младше хоста и меняли, допустим, инпут или таблицу - стили отлетали, т.к. в дочернем приложении ожидаются другие хеши для css классов (использовались scss modules). Это как раз случай, когда, вероятно, использовать singleton для библиотеки не лучшее решение, но у нас uikit непонятным образом весит больше 2мб (точнее понятным - некоторую графику загнали в base64 в css и еще куча других проблем) и это мрак полный. Пришлось смириться и быть внимательным, чтобы обновлять единомоментно

Проблема тут еще в том, что uikit нам поставляли со стороны и информациооная поддержка была не лучшего качества - очень долго выбивали ченджлоги, в итоге пришли к тому, переодически высалаются PDF (!!!!) с описанием изменений, про сторибук молчу, больше выглядел как лишняя примочка не понятно для кого

Мой опыт с Webpack 5 Module Federation

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

Мой опыт с Webpack 5 Module Federation

А с чем конкретно возникла сложность в типизации? У нас были проблемы в типизации бутстрапа (устали костылить и влепили мужицкий ts-ignore) и точку входа в дочь, если меняется стор ядра (приходится генерировать .d.ts и перекладывать руками в common), а так в остальном проблем не было

Мой опыт с Webpack 5 Module Federation

@movlпромахнулся веткой, извините

Мой опыт с Webpack 5 Module Federation

Сейчас собираемся перейти на NX, так как в других проектах он себя хорошо показывает

Я видел, что NX не поддерживает отдельные релизы подсистем, это дейтсвительно так и насколько больнно делать свои workaround'ы для этого?
У нас каждый фронт релизится отдельно, интересно попробовать спроецировать этот опыт на будущее и подготовиться :)

я так понял вы и сами с этим частично столкнулись

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

Спасибо за ваш отзыв!

Мой опыт с Webpack 5 Module Federation

начал смотреть на NX, но слишком поздно, под конец проекта. На другом проекте обкатывают коллеги лерну и она им больше не нравится, чем нравится. Думаю, NX будет следующим. Но это история не про module federation

Сам module federation выбрал по нескольким причинам:
1) Шаринг зависимостей. Не нужно писать костыли для определения инстансов бибилиотек.
2) Подкупили утверждения автора технологии по поводу экономии сетевого трафика и это на самом деле оказалось правдой
3) По сути, конфигурация простая, но выглядит заковыристо. Пару строк в конфиг вебпака, бутстрап для энтиропоинта - и микрофронтенды готовы к работе
4) Я слишком буквально воспринял фразу "подключить любое приложение в любой момент". Никто другой не мог на тот момент предложить, что можно встроить без костылей и лишних библиотек/фреймоврков механизм работы с приложениями. Да, было что-то уже в вебпаке плагинчик (не помню как называется), который позволял делать схожее, но причина ниже. Я ориентировался на то, что завтра/полгода/год с бухты-барахты заказчик притащит команду ангулярщиков, а мы все пишем на реакте (реакт был в требованиях тз). И нам как-то придется всем месте жить, а бизнес слышит про микрофронты и думает, что все просто.
5) У меня была абсолютная свобода действий. Я люблю работать с новыми библиотеками, и тут подвернулся такой шанс. Хотя, возможно, сейчас бы я не стал так рисковать как год назад. А тогда я увидел новую хайповую фичу и решил попробовать.

Да и возможно выбор module federation был yolo-решением и, слава богу, оно сыграло и опрадалось. Но, опять же, впредь я вряд-ли рисковать буду таким образом

Мой опыт с Webpack 5 Module Federation

Ну здесь можно и клеймами в JWT решить

Вы совершенно правы, но, как говорится, кто платит - тот и музыку заказывает :)

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

 остальное через feature modules можно решить

Если я не ошибаюсь, feature modules предполагает нахождение на одном сервере, а module federation позволяет тянуть части системы из любого места. Поправьте, если не прав.

Мой опыт с Webpack 5 Module Federation

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

Микрофроненды нашли хорошее применение в организации ролевого доступ к АРМ. Как я говорил в статье, у каждого приложения есть манифест и сервер о них знает. В зависимости от привелегий пользака, север формирует пул манифестов и отправляет его клиенту. Не обладая нужными правами, пользак при всем своем желании не попадет туда, куда не следует, просто потому, что ему этот микрофронт не доступен с домашней страницы. Конечно, он может попытаться по прямой ссылке пойти, но и там его ждет облом, но это уже немного другое

Целевая аудитория - системные администраторы, и у них есть разные уровни доступа. По требованиям ТЗ предполагается, что могут быть как локальные админы (администраторы структурной единицы в предприятия), так и супер админы (админ всего предприятия/нескольких предприятий, хоть всей РФ). Одни должны настраивать пул доменов, NTP, DNS и т.д., другим же достаточно предоставить доступ к управлению машинами, пользователям, принтерам.
При этом, объем системы большой и изменение в функционале точечно затрагивают модули, снижая время на CI/CD и вывод в релиз отдельных элементов системы или выноса функционала в отдельный домен.
К сожалению, были моменты корректировки ТЗ и на одной из крупных подсистем было очень много стихийных изменений, и мы бы уперлись в конфликты в репозитории и ожидании развертывания без микрофронтов, dev-стенд вообще по несколько раз в час обновлялся.

Так же, сильно ускорилась работа, были сформированы несколько команд/одиночных разработчиков, работающих абсолютно независимо друг от друга, без ожиданий очередей сборки с минимальными конфликтами в git

Более конкретно рассказать не могу, чтобы не получить по голове за разглашение :)

Надеюсь, ответил на Ваш вопрос, если нет, то уточните, где я свернул не туда

О чем вам не расскажут на курсах по Реакту. Вредные советы, как стать незаменимым разработчиком

почему нет совета использовать querySelector вместо ref? :) такое же тоже бывает

Библиотека react-svg-worlmap, ошибка в типах данных

1) 1k скачиваний крайне мало

2) почему не https://www.npmjs.com/package/react-leaflet ? Тут хотя-бы ~200к скачиваний

3) как-то странно, по сути статья сводится к тому, что кто-то изменил руками либу в node_modules и рассуждения вокруг этого? Это не то, что костыль, на это нормативной лексики недостаточно

Что мне не нравится в react-router

Поэтому ссылка на книгу будет выглядеть так: 

Когда в моем проекте пришёл момент этот, я переписал роты на статичные и все остальное перенёс в query. Жить стало значительно легче

Самый несущественный. Лишние пересоздания кокомпонентове

Если у вас такая проблема, то наверняка вы неверно, особенно с шапкой, организовали роутинг. Как уже сказали выше, ту же шапку можно вынести из роута и всё, а все остальное можно проверить в одном месте, где роутинг конфигурируется, даже тот же location.

Вёрстка в 2022. Часть 2: Практика

В первой части переизобрели бутстрап 4, во второй части в css уже видны проблемы отсутствия следования методологии какой либо

Для новичков материал суперский, но автору посоветовал бы пересмотреть подход к организации css, начиная с нейминга и раз вы используете scss - использовать миксины чаще и placeholder-классы. Даже "улучшенный" код можно ещё сократить, используя все выше, а спагетти из card-* упаковать в 3-5 строчек, используя map

Когда же нужно использовать useCallback

const [list, setList] = useState(listOfCities);
const handleClick = () => {
  setList([...list, newItem]);
};

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

Релизим фронтенд несколько раз в день

Не знаю, что за решение использует автор, но лично я смотрю в сторону Loki.

По поводу удобства не знаю, можете предварительно оценить по этому докладу (где-то в середине будет демонстрация Loki)

React испортил веб-разработку

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