Тупые и умные компоненты интерфейса. Илона Саркисова 

5:50 - "глупые" и "умные" компоненты есть не только в Angular, но и в React и Vue. Суть здесь не в зависимости от базы данных, а в возможности управления своим же состоянием. Глупые компоненты получают состояние извне, а умные могут изменять его самостоятельно, в т.ч. делая запросы к базе данных. Есть нюансы в проведении параллелей между концепциями "умных / глупых" компонентов в разработке и в дизайне. Концепция "глупого" компонента на 8:18 в целом соответствует этой же концепции в разработке, но стоит уточнить, что "глупый" компонент в разработке не содержит никаких состояний. В подобном случае в разработке в компоненте можно задать условие для отображения тех или иных его частей, в зависимости от входящей информации. Что касается концепции "умного" компонента на 8:50 - здесь вовсе нет пересечений с разработкой. Указанные компоненты с конкретной информацией/изображениями могут (и в общих чертах будут) являться глупыми, просто уже будут иметь какую-то конкретную информацию для отображения. То есть на том слайде (8:50) слева - "глупый" компонент до того, как в него пришла информация, а справа - с полученной информацией. Я бы немного переформулировал суть идеи того, что представлено в презентации. Вместо "Тупые и умные компоненты интерфейса" - "Компоненты и их инстансы (instance) в интерфейсах". Но смысл того, как необходимо подходить к разработке дизайна верный - компоненты должны быть продуманы так, чтобы их можно было использовать в разных частях проекта с разными входными данными. При этом должно быть несколько уровней: 1) Общий template (например, вверху header, затем контент, затем footer) - в случае с дизайном в фигме мы не будем делать всю страницу компонентом, но в разработке часто будет именно так, разработчик сделает template, в котором постоянно будет присутствовать один и тот же header и footer, и будет прокидывать в этот template динамичный оснвной контент. 2) Каждая часть общего template также является template, назовем условно section template. (Например, header будет состоять из логотипа, меню и иконки юзера). Здесь уже стоит делать компонент в фигме, внутри которого будут другие компоненты. 3) Каждая часть template из пункта 2 будет являться компонентом. (Например, иконка юзера будет отображать имя и фото юзера, если он выполнил вход на сайт, в противном случае будет отображать только надпись "Войти". То есть у этого компонента будет 2 возможные вариации (или два возможных типа инстанса) - "фото + имя" или надпись "Войти") И теперь, например, разрабатываем дизайн главной страницы в двух вариантах - юзер не вошел на сайт и юзер выполнил вход. И используем здесь тот самый компонент из пункта 3. В этом и будет суть переиспользуемых компонентов - мы не будем делать отдельные компоненты для этих двух случаев, просто используем продуманный существующий компонент, способный отразить нужную нам информацию при любом раскладе. p.s. Лайк за стремление связать дизайнеров и разработчиков. Чаще всего последние не шарят в дизайне, но хотя бы дизайнеры будут понимать, как слелать так, чтобы проект был лучше)

Такая четкая подача без воды👍 супер, спасибо)

Как в react используют компоненты? Если в каждом модуле заново создают стили

Спасибо. Интересно и четко рассказываете. 👍

Клааас! Очень полезное видео)

Классный спикер!

А можно ещё ссылку на medium? Очень интересно было бы почитать статьи на тему UX / UI

Не могу воспользоваться ссылка на файл Фигма, пишет ошибку. Как быть?

7 лет в UX, бакалавриат... тупые и умные компоненты... понты-понты. Епам, одним словом. Пойду ка лучше на канал Лёши Бычкова.