Комментарии 39
У нас в ките, есть даже редактор, который позволяет посмотреть какие свойства есть у компонента и тут же подправить их. Например: http://mol.js.org/#demo=mol_string_demo/edit/path
А в перспективе проектировщики интерфейсов смогут в нём собирать целые приложения из готовых компонент.
Почему вы сомневаетесь?
Вот чёрт, я надеялся проехаться на вашем опыте, а теперь придётся менять работу, чтобы понять ваши аргументы :-(
Для дизайнеров-оформителей будет отдельный интерфейс на "поиграться со шрифтами". Проектировщику интерфейсов же важнее что, где и как взаимодействует, а не как оно выглядит. Подробнее персонажей я расписал тут: https://github.com/eigenmethod/mol/projects
Начинающим девелоперам куда проще поправить через конктруктор, а потом посмотреть сгенеренный код, чтобы понять как такого добиться в дальнейшем уже руками.
конкретные требования бизнеса, которые могут быть очень изощренными(читай: нужна кастомизация на каждом шагу), даже после многочисленных согласований.
Могут быть, а могут не быть. Часто бизнес становится куда менее капризным, видя разницу в цене и сроках. Тем не менее с кастомизацией у нас более чем порядок, благодаря разделению композиции, поведения и оформления.
В коде он может делать все, что угодно, в вашем конструкторе все будет так: он потратит время пытаясь что-то сделать, поймет что этого сделать нельзя
Тот конструктор, что я привёл строится по исходным кодам композиции и будет обладать той же мощью. Поведение у программистов никто не забирает. А для кастомизации оформления для дизайнеров будет отдельный интерфейс.
Далее, у проектировщика интерфейсов уже и так есть опыт работы с инструментами, которые ему нравятся.
Мало ли что там ему нравится. Если каждый будет делать только то, что ем нравится — телега никуда не поедет.
А еще у него есть сроки на реализацию. Поэтому он не будет от них отказываться
Сроки не у него одного. Поэтому выбирается инструментарий и рабочий процесс выстраивается исходя из общей эффективности, а не только лишь одного рисования картинок.
оно не сможет тягаться с тем что уже есть у дизайнеров по количеству преимуществ: база готовых компонентов, скорость и удобство проектирования.
Называйте вещи своими именами, пожалуйста. Не "база готовых компонентов", а "база весёлых картинок". И на выходе из скетча тоже не более чем "весёлая картинка". Потом эта картинка передаётся программисту и он начинает "натягивать" её на те компоненты, что у него есть. И начинаются вопросы:
- Как эта хрень должна выглядеть в других разрешениях?
- А как тут показать ошибку / ховер / другие состояния, о которых дизайнер не потрудился подумать?
- А что делать если контента много / мало / нет вообще?
- А почему на этом экране отступ такой, а на том — другой? А если должно быть одинаково, то какой из-них правильный? И как и привести к одному виду, чтобы дизайн другого экрана не поехал?
А теперь сравните с вариантом использования конструктора:
- Дизайнер вместе с программистом разрабатывают UI Kit, состоящий из компонент, которые легко друг с другом стыкуются в любых комбинациях.
- Проектировщик интерфейса (который ни разу не "дизайнер" и не программист), собирает из компонент экраны, получая на выходе разные приложения, выполненные в едином опрятном дизайне, которые можно установить на любое устройство, с любой диагональю экрана и дать потыкать заказчику.
- Программист добавляет нетривиальную логику к по сути уже готовому интерфейсу приложения, без необходимости его полностью перелопачивать.
Вы правда считаете, что отрисовка десятков экранов из одних и тех же блоков помноженных на несколько размеров экранов и помноженная на десяток циклов перерисовки — это быстрее и приятнее дизайнеру? А потом натягивание этого "не ограниченного ничем креатива" на код — мечта программиста?
Начинающим девелоперам надо как можно скорее становиться не начинающими
И визуальный конструктор в этом куда лучше помогает, чем чтение документации. С чтением документации вообще беда у многих.
даже самые лучшие конструкторы сайтов, а у них примерно та же идея
Даже близко не та. У нас даже дрегендропа нет, и не факт, что вообще будет, так как цель конструктора — не нарисовать картинку, а спроектировать интерфейс :-)
Как и любой другой npm-пакет:
npm i --save @tinkoff-ui/buttonВторой вариант: развернуто на своих серверах.
Используется Nexus Repository Manager.
Кто-нибудь пробовал UI Kit Fabric от Microsoft: https://dev.office.com/fabric? Недавно наткнулся и успел немного поиграться, разнообразие компонентов и простота очень радует. Если кто-то использовал в продакшне, поделитесь опытом пожалуйста.
1. Есть ли у вас в компании Kit?
Да, но мы не выносим его в отдельный npm-пакет ни в целом, ни по частям. Подключаем внутри виджета.
2. Какие из проблем встречались вам?
— проблема унификации. Каждый член команды дорабатывает UI-компонент по своему усмотрению, могут быть конфликты и разница в нейминге;
— сложность стилизации. За основу собственной библиотеки компонентов взят React Material UI. Дизайнер создаёт макеты на основании своего видения процесса и бизнеса, не обращая внимание на что впринципе способен компонент. В результате не все фичи дизайна возможно реализовать.
— версионирование. Проблема перекликается с предыдущей. Предположим, что дизайн версии 1.1 был сделан на Material UI. Далее дизайнер придумывает нечто новое, что на базе Materual UI уже сделать невозможно. В итоге получаются два варианта: договориться с дизайнеров «забыть» о макете либо кардинально изменить компонент, взяв за основу другой npm-модуль и внедрив во все места использования. Второй вариант оказывается очень трудозатратным, поэтому часто приходится довольствоваться первым.
Отвечу, пожалуй, тоже :)
Есть ли у вас в компании Kit?
Да и несколько. Есть ядро совсем без стилей с базовой функциональностью, и есть киты под линейки продуктов, навешивающие на ядро стили и общую доп. функциональность. Потом это все используется в конечных проектах, которые в свою очередь так же добавляют свои стили и функциональность.
Какие из проблем встречались вам?
Расширение темы компонента и его функциональности/частей.
- Какие из указанных решений вы использовали и какую получили при этом пользу?
Сторибук используем, но старый, так как у нас куча плагинов под первый вебпак, несовместимых со вторым, а конфиги под сторибук и проекты одни.
Темизацию и расширяемость стилей компонентов сначала решали через react-css-themr (не используем css-in-js, только css-модули), потом проще стало написать и поддерживать свое решение в 100 строк.
Расширяемость функциональности и замену частей компонентов делаем через своего рода DI через props (и контекст). Если компонент рендерит другой в качестве чайлда, то он принимает ссылку на класс/функцию этого подкомпонента через props, а в defaultProps стоит стандартная реализация из импорта уровня модуля. За нужным интерфейсом подкомпонента следит TS черезComponentType<NeededChildProps>, так что можно точечно менять отдельный участки сложных компонентов. Например практически во всех проектах у нас разные календари в дейтпикере, но общая логика сохраняется.
Но тем не менее, возникали вопросы оформления этого самого кита, в основном это касалось нейминга: скажем, вот у нас некая жёлтая кнопка, как её правильно назвать: если, исходя из свойств, назвать её YellowButton (ну или Button[kind=«yellow»]), то мы будем ограничены спектром жёлтого для стилей этой кнопки (если захотим прикрутить «темы» к этому самому киту), а если называть исходя из предназначений, например DangerousButton (ну или Button[kind=«danger»]), то сложно придумать и обозначить все эти роли компонент. Особенно проблема возникала в текстовых элементах, там надо было как-то обзывать размеры и начертания текста… Если автор или кто-то из читающих знает как решать эти проблемы — с радостью бы послушал =)
Тут рецепт простой — спросить у того, кто рисовал, почему он нарисовал именно так. Если "потому, что это опасная кнопка, её надо по особому выделить", то и называть компонент "опасная кнопка". Если "этот текст должен вызывать радость", то соответственно "жизнерадостный текст", ну а если "мне так захотелось", то либо объяснить, что так делать не хорошо, либо ничего не остаётся кроме "странная особенность номер 341" :-)
В случаях с кастомизацией стиля компонента через параметры, мне кажется, что тут есть очень большой риск так разойтись в количестве этих параметров и их вариативности, что это будет мало чем отличаться от просто задания стиля через css, и сведёт на нет всю прелесть кита.
Проблемы React UI Kit-а и единой дизайн-системы, о которых вы не знали