Инпут не ультимативный как минимум из-за того, что нет мастера и придётся редактировать все варианты.
Если у вас есть разные инпуты: поиск, текст, почта с маской, числовой и тд — вы запаритесь редактировать все.
Да и настраивать каждый раз с дефолтного на, например, поиск, надоест) имхо
1. Ресайз не должен переносить текст на новую строку. Так никто не делает 2. Иконки все в одном компоненте. Зачем свойство Boolean тогда? 3. В инпутах бывает сброс (крестик). Как сделаете? Иконкой? Иконка - не интерактивный элемент 4. Лейбл и хелпер - такие же компоненты
я уж не говорю про то, что не хватает состояний и интерактивности
Сори, не ультимативно, но основы сборки поданы хорошо. Лайк
Раньше я всегда собирал отдельно .base компонент для редактирования, но по опыту буквально 1-2 раза за все время мне пришлось его отредактировать. Поэтому я и отказался от этого.
1) Ресайз, да, должен скрывать текст. Не отписал тут этот момент. 2) Да, иконки нельзя никогда хранить в вариантах. Я просто обернул их, чтобы показать, что они компоненты, а не просто валяются. Но это ввело в заблуждение, учту:)
Состояния в макете есть:) Интерактивность просто решил не описывать тут.
Дополню - 1 - самый первый компонент должен быть наиболее часто используемый. То есть ваши дизайнеры не должны тратить время на то чтобы добавить компонент из библиотеки и тратить время на отключение иконок, подсказок и тому подобного. 2 - Никогда. слышите? НИКОГДА - не объединяйте ассет иконок в один компонент как варианты. Во-первых он никак не сортируется внутри и все иконки будут будут предлагаться в хаотичном списке. Второе - в списке вариантов иконок нет превью это так же усложняет поиск компонента. И в-третьих это противоречит принципам Figma Properties - когда вы создаете instance swap properties это подразумевает что вы будете выбирать иконку не из вариантов этого компонента а среди отдельных компонентов (для удобства иконки компонентов организуют просто в отдельном артборде) 3 - Большие матрицы компонентов нагружают файлы - старайтесь делать более компактные компоненты. Например вам в компоненте не нужны состояния ховера, фокуса или например ассинхроной отправки данных - их можно отрисовать для документации а в компоненте оставить только те что вы реально используете постоянно. 4 - добавляйте обязательно Resizing Truncate Text для всех текста внутри поля чтобы он сокращался внутри инпута. (Не очень "ультимативно" если ваш компонент не предусматривает это поведение )
1) Самый первый компонент и есть самый используемый 2) Да, иконки никогда нельзя хранить в вариантах. Я просто собирал что бы было видно, что они являются компонентами. 3) Благодаря последнему автолейауту совсем больших матриц и не будет. Хранить отдельные компоненты в другом месте ерунда, так как за этим невозможно будет следить 4) Да, этот момент я просто забыл тут описать. Спасибо.
Автор молодец, но
Инпут не ультимативный как минимум из-за того, что нет мастера и придётся редактировать все варианты.
Если у вас есть разные инпуты: поиск, текст, почта с маской, числовой и тд — вы запаритесь редактировать все.
Да и настраивать каждый раз с дефолтного на, например, поиск, надоест) имхо
1. Ресайз не должен переносить текст на новую строку. Так никто не делает
2. Иконки все в одном компоненте. Зачем свойство Boolean тогда?
3. В инпутах бывает сброс (крестик). Как сделаете? Иконкой? Иконка - не интерактивный элемент
4. Лейбл и хелпер - такие же компоненты
я уж не говорю про то, что не хватает состояний и интерактивности
Сори, не ультимативно, но основы сборки поданы хорошо. Лайк
Раньше я всегда собирал отдельно .base компонент для редактирования, но по опыту буквально 1-2 раза за все время мне пришлось его отредактировать. Поэтому я и отказался от этого.
1) Ресайз, да, должен скрывать текст. Не отписал тут этот момент.
2) Да, иконки нельзя никогда хранить в вариантах. Я просто обернул их, чтобы показать, что они компоненты, а не просто валяются. Но это ввело в заблуждение, учту:)
Состояния в макете есть:) Интерактивность просто решил не описывать тут.
Спасибо за отклик:)
Дополню -
1 - самый первый компонент должен быть наиболее часто используемый. То есть ваши дизайнеры не должны тратить время на то чтобы добавить компонент из библиотеки и тратить время на отключение иконок, подсказок и тому подобного.
2 - Никогда. слышите? НИКОГДА - не объединяйте ассет иконок в один компонент как варианты. Во-первых он никак не сортируется внутри и все иконки будут будут предлагаться в хаотичном списке. Второе - в списке вариантов иконок нет превью это так же усложняет поиск компонента. И в-третьих это противоречит принципам Figma Properties - когда вы создаете instance swap properties это подразумевает что вы будете выбирать иконку не из вариантов этого компонента а среди отдельных компонентов (для удобства иконки компонентов организуют просто в отдельном артборде)
3 - Большие матрицы компонентов нагружают файлы - старайтесь делать более компактные компоненты. Например вам в компоненте не нужны состояния ховера, фокуса или например ассинхроной отправки данных - их можно отрисовать для документации а в компоненте оставить только те что вы реально используете постоянно.
4 - добавляйте обязательно Resizing Truncate Text для всех текста внутри поля чтобы он сокращался внутри инпута. (Не очень "ультимативно" если ваш компонент не предусматривает это поведение )
1) Самый первый компонент и есть самый используемый
2) Да, иконки никогда нельзя хранить в вариантах. Я просто собирал что бы было видно, что они являются компонентами.
3) Благодаря последнему автолейауту совсем больших матриц и не будет. Хранить отдельные компоненты в другом месте ерунда, так как за этим невозможно будет следить
4) Да, этот момент я просто забыл тут описать. Спасибо.
Интересный подход, полезная статья!
Топовое оформление статиьб
Эх, получаецо пролистываем🥲