Comments 15
Одно дело хорошо верстать, другое – качественно создавать архитектуру библиотеки. Важно задумываться о том, что поставляешь пользователю библиотеки, и поэтому vue-cli-service совсем не подходит. В вашем случае было бы уместно обернуть проект в Rollup и настроить оптимизацию и минификацию, выпилить external dependencies из бандла. В конце концов, ни в коем случае нельзя использовать Moment JS, особенно вместе с Date-fns. Во-первых, они делают одно и то же, так что вы просто дублируете код. А во-вторых, просто зайдите в readme moment'а и сами все поймете.
Также хорошая библиотека будет использовать современные инструменты ради улучшения Developer Experience: Vue 3 с composition API для быстродействия, TypeScript для читаемости и документации на уровне кода, Vite для одновременно и бандлинга и настройки демо-проектов.
Иконки в виде .vue компонентов – тоже вредно. Вероятнее всего, у пользователей библиотеки есть свои .svg- иконки, и они захотят прокинуть их в компонент через slots. Говорили о недостатках существующих компонентных библиотек, а сами на них наткнулись.
Используйте только относительные пути для импорта чего-либо в javascript ваших компонентов. Не используйте «абсолютные» алиасы
Зачем? Дайте хоть одно объяснение такому импорту в вашей статье. Кто-то ведь пойдет копировать такой деструктивный код.
Непонятно, зачем вы залили library starter на npm, если это шаблон кода. В тексте статьи всю вторую половину можно было бы опустить в пользу понятного readme на гитхабе, а первую – сделать читабельной с помощью дробления на мелкие абзацы и секции.
Ого, понеслась!.. Но, прежде всего - от души спасибо за такой подробный, разгромный "не в бровь а в глаз" классически пассивно-агрессивный, но предельно предметный и вежливый ответ. Серьезно. Я вот на Хабре только камменты читаю, особенно когда такие пассивно-агрессивные вдумчивые)))... Баталии в камментах это ... призвание...)))
Во-первых, вы, конечно, во всем практически "правы" и ваш оверинжириниг ваши актуальные познания просто блестящи, очевидно. Наверняка вы трудитесь программистом тимлидом-сеньором, поэтому мне - простому дизайнеру и верстальщику в адовом аутсорсе остается только стыдливо краснеть, мычать и отмазываться как смогу... Слишком разный, вероятно, опыт и восприятие. Само мое техническое решение решение это действительно - хоть и основанный на опыте некоторых предыдущих реальных коммерческих проектов, но быстрый пример "из того что было ..." - в принципе никак не претендующий на безукоризненную идеальность. Кроме того я рассказываю ну совсем о другом - скорее о неких "гуманитарных" идеях и вещах - навроде - "простой доставке атомарного дизайна в код с помощью "5 лет назад как похороненных" препроцессоров" - подходах, которые обычно игнорируют программисты с сухим сугубо техническим восприятием... И вот в этом смысле - вы откровенно передергиваете, но наверняка не сможете это осознать-признать.
Про Rollup - ок, но повторюсь - статья о другом. Датапикер-диапазон на одном листе и с кварталами - был добавлен в последний момент, и это форк который, действительно - есть еще в чем улучшать, что из него выпиливать, исходник был еще сильно хуже - вот про Moment JS, особенно вместе с Date-fns - вы совершенно правы, конечно же - надо найти на это время. На самом деле, когда читаешь такие камменты, аж завидно становится - вот все эти моменты пришли с реальных проектов в которые я попадал последние годы в своем аутсорсе - на достаточно именитые фирмы... И там такое - не будем... Видимо, где-то есть спокойные продукты на которых настоящие синьеры могут спокойно заниматься себе оверинжинирингом аккуратной кастомизацией бандла и тд. Поверьте в реальном коммерческом фронтенде - в вполне даже приличных конторах - иногда идет речь о том чтобы смотивировать коллег просто даже писать компонентами на компонентном фреймворке, например... Vue cli, фейл с моментом или использование неидеального vue-select (с которым в свое время пришлось ох как повоевать) - оно на самом деле приближает пример к реальности.
Далее продолжается совсем "выставка тщеславия". Vue 3 с composition API для быстродействия, ну а почему не Svelte тогда если о быстродействии речь? ))) Я вот его посмотрел и он мне ну прямо очень понравился именно дизайном и для дизайна, хочется что-нибудь на нем реальное написать, но наверное, все-таки не либу, в виду того что, утрируя: "датапикер под форк не найдешь"... Vue 3 начинал ковырять, и даже с TS, чтобы себя заставлять ), но вроде в доках написано что "еще не стабильно на прод"? ) Ну и вот это сказки все про ts... В реальной ситуации когда надо ну "дофига всего сверстать очень быстро и тд" - "скрипач не нужен"... Про Vite не понял про настройку демо-проектов...
Про иконки вы категорически не правы. Как раз - сильно вреден слот, "свои или какие-то левые иконки" и какая-нибудь "подгонка viewBox" при этом. Иконки должны быть все четко нарисованы дизайнерами в UI-ките - на SVG-холстах с одинаковым размером - только тогда проблем не будет. И все равно при этом очень часто бывает нужно "пойти в SVG как в код" именно. А в контексте либы нужен аккуратный учет, "перечень" - и чтобы "в одном месте лежали". Эта придирка уже явно говорит о том у вас мало релевантного опыта именно со стороны дизайна и верстки - вы не совсем понимаете о чем я вообще пишу - ну я был готов что будут минусы от "фуллстеков" и "лидов-синьоров".)))) Я готов что статья вообще по итогу в минус улетит, но надо было выговориться и некоторые вещи показать для удобства коммуникации с потенциальными будущими коллегами.
Про импорты... Вообще пару лет назад мы с партнером-фуллом пилили проекты для заказчика у которого вот как раз классический кейс - разные отделы пилят разное на якобы "одном фирменном стиле", но который, еще, на самом деле, не был никак формализован четко в руководство по стилю и тд и тп... Мы продали им в результате либу которая все это мерджила в единый стиль и документацию... Но сделано было так, что по некоторым выходящим за рамки этого холивара причинам в том числе и "корпоративного свойства" - либа устанавливалась и обновлялась не как npm-модуль в @/node_modules а в отдельную папку в сорцах проекта @/scr/library. Ну и при такой конструкции - в контексте проекта, данный импорт будет искать зависимость в директории @/node_modules проекта, а не библиотеки! Так как случай из реальной коммерческой корпоративной практики - значит вполне вероятен. Но расшифровывать подробность показалось излишне, переборно... А чем вообще аккуратные относительные импорты "деструктивны" то? )))
Ну и по поводу - "зачем на npm" - прямо совсем не смешно... Там, поглядите, кроме самого "шаблона кода с доками", есть еще и получившаяся в результате тестирования "очищенная версия" https://www.npmjs.com/package/ui-library-starter-test и использующий его проект в github и на vercel: https://ui-library-start-test.vercel.app/. Занимался, знаете ли - проверял то что написал... Вообще, одной из причин писать на Хабр считаю что вот такие пассивно-агрессивные комментаторы дают отличную возможность прорабатывать рефлексию, синдром самозванца и прочие эффекты, расти и развиваться... Спасибо что комментируете!
Пишу то я отлично, не надо - ну как "техпис" точно... Ну и правда - вы не очень поняли о чем статья... Она не о "идеальной современной технологии для реализации библиотеки", а о "способе доставки атомарного дизайна в код" и "правильной организации верстки"... Я вот последние месяцы - тружусь в корпорации с очень громким названием, но API - никак не заработает при этом, беда на бекэнде не заканчивается... Зато у них просто шикарный UI-кит... Либу делать нельзя - по "корпоративным причинам"... "Сборку" также - тупо Nuxt который по сути не нужен... Ну так я просто кинул роут @/pages/ui - и пилю там все - атомы-молекулы-организмы-шаблоны, обертки над сторонними модулями, примеры на мокках с простейшей "псевдодокументацией"...
Вау! Если честно, в "коммент-баталиях" еще никогда не участвовал. Благо, мы можем общаться конструктивно.
Совсем не хотел в комменте выше показаться токсичным. Мы и правда говорим о разных вещах. Вы – о лучших практиках в верстке, я – о хорошей библиотеке компонентов с архитектурной точки зрения. Уловить вашу точку зрения, правда, было крайне сложно – статья уж слишком большая, и большинство ее просто не осилит.
Ага, тогда - мир! И наверное это действительно минус моей работе что не очень четко основной мессейдж прозвучал... С другой стороны, "более лучшие модные модули" - мне все-таки не кажутся "архитектурным" моментом - вы говорите о конкретных реализациях и оптимизации. А вот то как "проектирование коммуницирует с разработчиками" или очень важный момент про "не надо обвязывать UI-компоненты напрямую" - как раз именно - архитектура. Мне вон там уже один минус прилетел за то что "статья плохо оформлена" даже - картинки для привлечения внимания не понравились, видимо... )))
Удалите картинки-плакаты - хоть под кат (если они вам дороги), их слишком много и они большие, а также убрать сопли про то, что кругом все пропало (имхо).
Как начинающий фронтендер честно пытался осилить, но "что-то пошло не так". возможно из-за того, что четко не обозначены "плюшки" данной простыни (стартовые цели -> что хотим получить -> как получаем -> преимущества и недостатки решения).
Спасибо за фидбек! Но "не котиками едиными" - советские плакаты тоже прекрасны, создают нужную атмосферу - как и котиков их может, должно быть много?... ))) Ну и меня вот такой стиль специфический, фриковатый! )))
По поводу того "в чем соль": статья о том как "подружить дизайн с кодом" "не оставив шансов мракоделам которые тупо копируют как попало вьюху" и "срать хотели не интересуются тем что там у дизайнеров", "атомарный дизайн не слышали" (сейчас вот в Фигме можно "указывать атомы", например, а не только сами компоненты)... Еще когда я писал первую статью казалось "что CSS-in-JS похоронили препроцессоры" - даже если камменты там почитать - тогда адцке забурлило у многих... Но вот теперь - с атомарным дизайном - "шах и мат, программисты!"... Рано они похоронили абстракцию в стилях, короче...
Молодой человек, moment удален с версии 1.1.0! )))
А почему выбрали stylus?
Если честно - просто потому что он на текущих проектах и можно было "просто скопипастить и переименовать атомы" ))))... Ну вот такой кодестайл как я сейчас использую еще и действительно очень аккуратно-лаконичный и "очень идет" этому остальному "совсем мало кода в компонентах" - все выглядит очень легко и изящно... ))) На самом деле, в контексте данной темы нет ну никакой разницы - суть в том, что ваш код "дружит" с "атомарностью" дизайна, а какой препроцессор и фреймворк использовать - не важно. Просто многие "тимлиды-сеньоры" - давно и плотно подсели "на иглу" унылого CSS-in-JS - что снимает с них ответственность и необходимость "якобы лишней" коммуникации с проектированием и между-собой... Ну и вообще - "верстка - удел джунов", "настоящим программистам" "это уже не интересно"... А потом вдруг - "все горит" и приходится целые репо переписывать... Потому что в реальности - существует очень много задач и интересного современного дизайна который невозможно реализовать вот так - "как угодно - копипастой", "с помощью некастомизируемых готовых дизайн-систем", "джун пишет стилевые обертки, наборы правил" и тд и тп... Я, например, могу описать реальную ситуацию "нереального дедлайна" - "огромный кастомный и очень важный сайт" - который начали "примерно когда надо было сдать" - недавно адцке вывозил - когда "подробную компонентность" - просто ну никак не успеть, хоть с препроцессором, хоть с CSS-in-JS (тем более, потому что не оптимально)... И еще вот - "целый репо стартового гавна" - и олдовые фуллы-PHP-шники "которые возомнили себя фронтами" - "еще копируют", ну и, самое главное, по классике - макеты продолжают перерисовываются всю дорогу, гаджеты приезжают только после сдачи десктопа - и тд и тп... А проект "ну очень серьезный, очень серьезные заказчики" - не будем... Так вот - в такой ситуации реально вывезти можно только "с помощью старых-добрых глобальных стилей", но оптимизированных через препроцессор - настолько насколько времени хватило, успел... Важно просто понимать что делаешь и для чего, ну и иметь реальный разнообразный опыт, пробовать разное...
Давайте, прежде всего, четко обрисуем проблему которую мы собираемся решать
Так давайте же! А то дальше несколько экранов текста про мракоделов и капитализм. Написано живо и эмоциально - что есть, то есть. Но очень уж размыто. Мысль я так и не уловил.
Вам не трудно было бы уточнить (в одном-двух предложениях), в чем конкретно проблема, с которой боремся. Можно с примерами кода для наглядности. Спасибо!
Затем вы переходите к описанию методики, которая решает эту проблему. Но на самом деле, это не методика, а туториал по использованию какого-то стартового шаблона. Методика - это все-таки по подходы, а не про инструменты / реализацию. Именно по подходам, я увидел в статье рекомендации использовать миксины для переиспользуемых блоков стилей и константы для цветов/брейкпойнтов. Что, конечно, хорошо и правильно, но как-то на методику не тянет.
Меня не покидает мысль, что я упустил что-то основное и главное в статье, без чего пазл не складывается.
Спасибо, за адекватный комментарий! )) Вы, конечно, правы - статья получилась хоть и замечательно злая во вступительной лирической мотивационной части, но достаточно невнятная тезисно, да еще и с внезапно резким переходом в занудно простой пример... Ну я не знаю что делать со своей графоманией и витиевато-разнузданным слогом - какой есть... Вот пытаюсь собраться, сконцентрироваться - а все равно больше двух предложений получается... )))
Наверное я все-таки плохой "теоретик", университетов не кончал, курсов не посещал, книжек не читал толком - было некогда - приходилось все время много работать... Но, кажется - "общая методика" вкратце изложена в конце раздела статьи "Разрабатывайте визуальный язык и основанные на нем шаблоны своих интерфейсов через простые четкие соглашения и документирование, а не хаотическое копирование!!!" - список из трех советов-абзацев?
1) Проектирование/дизайн и разработка/код должна говорить на одном языке
2) Оцениваем объем работ, производим декомпозицию задач и проектируем компонентную структуру проекта именно с точки зрения элементов этого языка - "считаем компонентами, а не макетами", если совсем тупо
3) Отделяем бизнес-логику на видах от этого абстрактного визуального языка выраженного в виде конкретной кодовой базы - библиотеки UI, переиспользуемых компонентов. Виды предоставляют данные в компоненты через пропсы, явный интерфейс. Не обвязываем компоненты напрямую со стором состоянием. Важно!
А далее следует не методика, а "пример простой реализации" - показывающий как элегантно можно доставить "атомарный дизайн" в код компонентного фреймворка с помощью абстракций препроцессора. CSS-in-JS реализации или тем более - "готовые дизайн-системы-фреймворки" для этого непригодны.
Так лучше?
Спасибо, так понятней!
Не вполне очевидно, почему
CSS-in-JS реализации или тем более - "готовые дизайн-системы-фреймворки" для этого непригодны.
Достаточно сложно написать статью с примерами "ужасного кода" - так как я сам такой не пишу, а то что приходится встречать по работе - под NDA, понятно... "Изображать" - ну посмотрим - ну такая статья точно в минус улетит, разозлить тимлидов-сеньеров и прочих фуллстеков... ))) Но может быть, когда нибудь устрою и такое "неконструктивное" бурление-кипишь... )))
Здесь есть пассаж: "Например, попытки посадить Styled Components на дизайн-константы приводят к безобразному коду в таких «стилях»... Или утилиты «ишак вижу — ищак пою» «в стиле Taiwind» вполне способны представлять «атомы», но все равно ограничивают гибкость в случае непрогнозируемых и частых изменений, ну или просто — также выглядят излишне-невменяемо уже на самой разметке."
В первой книжке тоже есть и со ссылками - нам мои аккуратные попытки-примеры https://good-layout-book.netlify.app/start/ - глава Препроцессоры, раздел Styled Components:
"Для полноты повествования, в теме про компонентность нельзя не вернуться к альтернативному направлению развития CSS-технологий, упомянутому в самом начале. Возможно ли реализовать некоторые из рассмотренных выше преимуществ глобального препроцессора используя CSS-in-JS подход, например, Styled Components? В некотором ограниченном виде - да, возможно.
Мы легко можем использовать javascript для того чтобы определить объект с глобальными константами на которые в дальнейшем и будем опираться в единообразном и управляемом оформлении компонент. То есть, сформировать гайдлайн, и, например, стандартизировать в нем цвета и брекпоинты.
Безусловно полезным будет поэкспериментировать с этим, я сделал несколько попыток:
Очевидно, что код который в таком случае приходится писать, кажется, выглядит достаточно пугающе, неловко и неуклюже. Впрочем, и без попыток стандартизации значений у этих технологий присутствуют странности, вот, например, если нам нужно запилить картинок в бекграунд.
Кроме того, понятно что, во всех остальных аспектах наше оформление останется плоским и изолированным по компонентам, глухим и несвязным. Любая переиспользуемость будет ограничена компонентностью и заключатся только лишь в ней. Кто-то в какой-то ситуации может быть заинтересован как раз именно в такой строгости и скуке. Может быть вы неспешно пилите продукт с минималистичными простыми видами, скудным оформлением интерфейса... Но в самом общем случае, для быстрой работы со сложными макетами этот подход пока что представляется очень сомнительным и неудачным, ограниченным."
По поводу всяких Vuetify или AntDesign - ну вообще нет сил что-то доказывать. Я много лет всем этим занимался - это несовместимо даже просто "с хорошим дизайном и версткой", не только "атомарным трендом" отличным... Если для вас это не очевидно - значит у вас нет с этим достаточного опыта, ну и, вероятно - это вам не нужно. А надо будет - поймете на собственной боли. ))
Левон, а если в компании несколько стеков, например Vue, React, а ещё есть мобильные приложения, как бы ты автоматизировал управление UI'ем всех проектов компании?
Ммм... Ну, во-первых: "не используйте React", прежде всего. )))) Шутка, конечно, но вот мое отношение к этому фреймворку именно такое. ))) Ну а если серьезно, в случае если мы имеем некоторое легаси и на React и Vue, видимо, придется построить две "одинаковых кастомных библиотеки" для обоих фреймворков - с одинаковой номенклатурой компонент и полностью идентичным препроцессором (для гаджетов, наверняка, также можно построить библиотеку со схожим набором компонент и оформлением в фирменном стиле, но - с учетом особенностей этих сред и технологий). То о чем я пишу выше совсем не о конкретной технологии, а скорее о том, что очень многие разработчики не хотят ничего знать про дизайн или мощь препроцессоров, сильно противяться любой унификации и стандартизации, имеют мало опыта в создании качественной кастомной вьюхи, верят в то что "бутсрап им поможет" и так далее... Вот таких разработчиков очень полезно "оградить" от того что они не умеют и знать не хотят - просто выдав им готовую реализацию кита, компоненты, обязательно - документацию к ним и несколько перечней переменных и миксинов - атомов (если это веб - React, Vue, Svelte и тд) - для крайних случаев когда им все-таки нужно что-то "поверстать" на видах. Упрощая: будет очень эффективно если над написанием подобных библиотек, визуальными решениями будут трудиться разработчики с хорошей версткой, "лирики", а "физики" - работать на конечных видах - pages - с данными. Это в идеальном случае, конечно.
Но! В реальности все бывает не так идеально. Вот тут, как мне кажется - "ручной атомарный препроцессор" - как раз и будет очень эффективен. Так как научиться считывать из Фигмы маркер для цвета или гарнитуры шрифта - это вопрос минимальной дисциплины и контроля за кодом приходящим в репозиторий. Библиотека и ее готовые решения все равно никогда не покроют все случаи и далеко не каждое исключение дизайнеры захотят сводить к правилу и распрастранять на всю систему. Клиенты капризные, проекты разные, иногда (и даже очень иногда) бывает нужно чточто "вчера". Показанный выше "ручной подход", если ему аккуратно следовать - гарантирует что "исключительных стилей" на видах или "специфических компонентах проекта" - будет ну совсем немного и они будут "точно по киту". Их всегда можно будет быстро и легко отрефакторить при необходимости.
Как правильно верстать 2, или зачем я написал еще одну UI-библиотеку, мой первый npm-модуль?