Pull to refresh

Comments 39

UFO just landed and posted this here
Хорошая библиотека с большим числом компонентов. Можно найти ряд хороших практик. Отличный инструмент для решения собственных проблем компании :) Ничего более детального не скажу, так как знакомилась с ним лишь поверхностно.
UFO just landed and posted this here
Сейчас и дизайн достаточно сильно различается между проектами. Мысли были сделать переиспользование стилей, но из-за больших различий в принципах написаний стилей, технологий и шаблонизаторов пока отказались от идеи.
UFO just landed and posted this here
Привет, спасибо за вопрос!
Дизайнеры используют abstract (git для дизайнеров) и semver для версионирования компонентов. Когда разработчик получает макет, он видит из каких компонентов и из каких версий компонентов он собран.
UFO just landed and posted this here
Совсем в скором времени от нас выйдет статья, именно на эту тему!) Так что, следите за блогом компании ;)
Но в целом, у нас очень походе на то, что описано + abstract еще :)

У нас в ките, есть даже редактор, который позволяет посмотреть какие свойства есть у компонента и тут же подправить их. Например: http://mol.js.org/#demo=mol_string_demo/edit/path
А в перспективе проектировщики интерфейсов смогут в нём собирать целые приложения из готовых компонент.

UFO just landed and posted this here

Почему вы сомневаетесь?

UFO just landed and posted this here
Все верно, решений много. Но не все он так плохи :)
UFO just landed and posted this here

Вот чёрт, я надеялся проехаться на вашем опыте, а теперь придётся менять работу, чтобы понять ваши аргументы :-(

UFO just landed and posted this here

Для дизайнеров-оформителей будет отдельный интерфейс на "поиграться со шрифтами". Проектировщику интерфейсов же важнее что, где и как взаимодействует, а не как оно выглядит. Подробнее персонажей я расписал тут: https://github.com/eigenmethod/mol/projects


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

UFO just landed and posted this here
конкретные требования бизнеса, которые могут быть очень изощренными(читай: нужна кастомизация на каждом шагу), даже после многочисленных согласований.

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


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

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


Далее, у проектировщика интерфейсов уже и так есть опыт работы с инструментами, которые ему нравятся.

Мало ли что там ему нравится. Если каждый будет делать только то, что ем нравится — телега никуда не поедет.


А еще у него есть сроки на реализацию. Поэтому он не будет от них отказываться

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


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

Называйте вещи своими именами, пожалуйста. Не "база готовых компонентов", а "база весёлых картинок". И на выходе из скетча тоже не более чем "весёлая картинка". Потом эта картинка передаётся программисту и он начинает "натягивать" её на те компоненты, что у него есть. И начинаются вопросы:


  • Как эта хрень должна выглядеть в других разрешениях?
  • А как тут показать ошибку / ховер / другие состояния, о которых дизайнер не потрудился подумать?
  • А что делать если контента много / мало / нет вообще?
  • А почему на этом экране отступ такой, а на том — другой? А если должно быть одинаково, то какой из-них правильный? И как и привести к одному виду, чтобы дизайн другого экрана не поехал?

А теперь сравните с вариантом использования конструктора:


  1. Дизайнер вместе с программистом разрабатывают UI Kit, состоящий из компонент, которые легко друг с другом стыкуются в любых комбинациях.
  2. Проектировщик интерфейса (который ни разу не "дизайнер" и не программист), собирает из компонент экраны, получая на выходе разные приложения, выполненные в едином опрятном дизайне, которые можно установить на любое устройство, с любой диагональю экрана и дать потыкать заказчику.
  3. Программист добавляет нетривиальную логику к по сути уже готовому интерфейсу приложения, без необходимости его полностью перелопачивать.

Вы правда считаете, что отрисовка десятков экранов из одних и тех же блоков помноженных на несколько размеров экранов и помноженная на десяток циклов перерисовки — это быстрее и приятнее дизайнеру? А потом натягивание этого "не ограниченного ничем креатива" на код — мечта программиста?


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

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


даже самые лучшие конструкторы сайтов, а у них примерно та же идея

Даже близко не та. У нас даже дрегендропа нет, и не факт, что вообще будет, так как цель конструктора — не нарисовать картинку, а спроектировать интерфейс :-)

UFO just landed and posted this here
UFO just landed and posted this here
Не обращайте внимание на сомнения! :) Отличная задумка – нужна искать верно применение.
Где и как вы храните компоненты? Используете ли вы пакетный менеджер? В своих проектах с использованием библиотеки у вас есть какая-то структура организации каталогов, файлов и кода, или структура каждого проекта отличается?
Спасибо за вопрос! Упустила из статьи подробности. Используется свой npm внутри компании :) Каждый компонент – это отдельный пакет и любой желающий устанавливает его себе в проект, установив необходимый npm registry.

Как и любой другой npm-пакет:
npm i --save @tinkoff-ui/button
Вы используете приватный npm или развернули его на своих серверах? Поделитесь секретом, как вы это сделали :)

Кто-нибудь пробовал UI Kit Fabric от Microsoft: https://dev.office.com/fabric? Недавно наткнулся и успел немного поиграться, разнообразие компонентов и простота очень радует. Если кто-то использовал в продакшне, поделитесь опытом пожалуйста.

У меня, к сожалению, такого опыта не было.
Но может кто-то из здесь присутствующих коллег пробовал?..
Слушал доклад вживую, отличная подача, завидую твоим повествовательным навыкам.
Спасибо! Приятно слышать :)
Очень актуальная тема! Отвечая на вопросы:

1. Есть ли у вас в компании Kit?

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

2. Какие из проблем встречались вам?

— проблема унификации. Каждый член команды дорабатывает UI-компонент по своему усмотрению, могут быть конфликты и разница в нейминге;
— сложность стилизации. За основу собственной библиотеки компонентов взят React Material UI. Дизайнер создаёт макеты на основании своего видения процесса и бизнеса, не обращая внимание на что впринципе способен компонент. В результате не все фичи дизайна возможно реализовать.
— версионирование. Проблема перекликается с предыдущей. Предположим, что дизайн версии 1.1 был сделан на Material UI. Далее дизайнер придумывает нечто новое, что на базе Materual UI уже сделать невозможно. В итоге получаются два варианта: договориться с дизайнеров «забыть» о макете либо кардинально изменить компонент, взяв за основу другой npm-модуль и внедрив во все места использования. Второй вариант оказывается очень трудозатратным, поэтому часто приходится довольствоваться первым.
Спасибо за развернутый ответ!)

Отвечу, пожалуй, тоже :)


  1. Есть ли у вас в компании Kit?
    Да и несколько. Есть ядро совсем без стилей с базовой функциональностью, и есть киты под линейки продуктов, навешивающие на ядро стили и общую доп. функциональность. Потом это все используется в конечных проектах, которые в свою очередь так же добавляют свои стили и функциональность.


  2. Какие из проблем встречались вам?
    Расширение темы компонента и его функциональности/частей.


  3. Какие из указанных решений вы использовали и какую получили при этом пользу?
    Сторибук используем, но старый, так как у нас куча плагинов под первый вебпак, несовместимых со вторым, а конфиги под сторибук и проекты одни.
    Темизацию и расширяемость стилей компонентов сначала решали через react-css-themr (не используем css-in-js, только css-модули), потом проще стало написать и поддерживать свое решение в 100 строк.
    Расширяемость функциональности и замену частей компонентов делаем через своего рода DI через props (и контекст). Если компонент рендерит другой в качестве чайлда, то он принимает ссылку на класс/функцию этого подкомпонента через props, а в defaultProps стоит стандартная реализация из импорта уровня модуля. За нужным интерфейсом подкомпонента следит TS через ComponentType<NeededChildProps>, так что можно точечно менять отдельный участки сложных компонентов. Например практически во всех проектах у нас разные календари в дейтпикере, но общая логика сохраняется.
Здравствуйте, вы не могли бы пояснить каким образом у semantic-ui react получилось 16 компонентов? Вы точно имели ввиду официальный? react.semantic-ui.com
У нас пока ui-kit в зарождающейся стадии, ещё не столкнулся с проблемой версионирования (находится в той же самой репе, что и сам проект) и заточенности под нужды конкретного продукта (используется в одном продукте)

Но тем не менее, возникали вопросы оформления этого самого кита, в основном это касалось нейминга: скажем, вот у нас некая жёлтая кнопка, как её правильно назвать: если, исходя из свойств, назвать её YellowButton (ну или Button[kind=«yellow»]), то мы будем ограничены спектром жёлтого для стилей этой кнопки (если захотим прикрутить «темы» к этому самому киту), а если называть исходя из предназначений, например DangerousButton (ну или Button[kind=«danger»]), то сложно придумать и обозначить все эти роли компонент. Особенно проблема возникала в текстовых элементах, там надо было как-то обзывать размеры и начертания текста… Если автор или кто-то из читающих знает как решать эти проблемы — с радостью бы послушал =)

Тут рецепт простой — спросить у того, кто рисовал, почему он нарисовал именно так. Если "потому, что это опасная кнопка, её надо по особому выделить", то и называть компонент "опасная кнопка". Если "этот текст должен вызывать радость", то соответственно "жизнерадостный текст", ну а если "мне так захотелось", то либо объяснить, что так делать не хорошо, либо ничего не остаётся кроме "странная особенность номер 341" :-)

Не очень понял необходимость в «customize style of component», разве не в том прелесть кита, что он уже имеет встроенные жёстко заданные стили, на которые могут влиять разве что темы ну или в некоторых случаях параметры компонента?

В случаях с кастомизацией стиля компонента через параметры, мне кажется, что тут есть очень большой риск так разойтись в количестве этих параметров и их вариативности, что это будет мало чем отличаться от просто задания стиля через css, и сведёт на нет всю прелесть кита.
Sign up to leave a comment.