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. Лайк за стремление связать дизайнеров и разработчиков. Чаще всего последние не шарят в дизайне, но хотя бы дизайнеры будут понимать, как слелать так, чтобы проект был лучше)
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, бакалавриат...
тупые и умные компоненты... понты-понты.
Епам, одним словом.
Пойду ка лучше на канал Лёши Бычкова.
ага идите, научитесь все делать фиолетовеньким и... всё...)
@@irishwayлеша Бычков сдела для обучения гораздо больше чем вы. Вы только пукаете!!!