Оптимизировал bem-components, для удобной кастомизации их цветов.
- Вытащил все цвета, которые были в файлах common.blocks/компонент/_theme/компонент_theme_island.styl. Получился 31 цвет (вместе с оттенками, прозрачностями итд). Часть их была в hex, часть в rgba. Где-то прозрачность была в формате .n, где-то 0.n
- Привел все к hsla, чтоб были наглядно видно основные цвета
- Разбил цвета(оттенки) на группы, по основным цветам
- Вытащил в переменные основные цвета: $base = #000 $active = #070 $link = #44b $project = #fc0 $alert = #e00 $normal = #f6f5f3
- Задал hue, saturation, lightness, opacity через Stylus
- Создал файлик design/colors.styl и импортировал его в стили компонентов
Процесс оптимизации - http://codepen.io/koloskof/full/gaNGgB/
Что получилось - https://github.com/koloskof/bem-custom-components
Скриншот - http://koloskov.kz/bem-custom-components.png
Сейчас легко манипулировать цветами, меняя значения переменных базовых цветов. Подскажите удачное ли это решение? Что можно улучшить? Или вообще как-то по-другому сделать?
Ты проделал крутую работу! Было бы сильно круче если бы ты сделал ещё и проект со своей темой которую можно легко менять. Типа твой скин. :) это бы прям всем пригодилось еще больше. Скажи если решишься на такое, хоть чем нибудь помогу. Просто не всем подходит тема яндекса, хотя — менять цвета, уже много! :)
Пожалуй @teryaew это пригодиться. Я тоже могу за использовать :)
Спасибо тебе!
Хорошо бы сделать скин material design и инструкцию, как делать свои скины.
cc @yekver
Спасибо! По поводу своей темы/скина, такая задумка и была. Появилась инициатива кастомизировать bem-components под семейство рабочих проектов. Первым делом начал с цветов. Без инструкции "Как писать свои темы", конечно же никуда, так как действительно много возможных параметров для модификации. Продолжаю копать дальше. Буду вас спрашивать в процессе!
У нас на n последних проектах обычно есть в стартовом ките уровень project.components (блоки для проекта мы пишем в project.blocks), который является почти копией уровня дизайна с темой островов, только с модификатором:
{ theme : 'project' }. Почему так? Удобно кастомизировать компоненты на одном уровне, а не раскидывать по разным, как мы делали раньше. Плюс шаблоны блоков иногда там же доопределяются. Плюс мы отказались от stylus в пользу postcss :) Ещё как-то загнались на одном проекте, вынесли всё в переменные, в стиле бутстрапа, но не очень удобно оказалось пользоваться, я лично предпочитаю только цвета + шрифты. Исходили из опыта неоднократных стилизаций bem-components на мелких и средних проектах.Ещё это позволяет иметь на проекте витрину, по типу такой, по которой сразу можно подготовить компоненты и вынести работу с ними в единый временной отрезок, что, кажется, помогает с понимаем и ориентацией в проекте.
Мить, ну собстевнно это тоже самое что уровень
design/в bem-components ;)У меня такой же не очень хороший опыт с глобальными переменными. Пришел к пониманию что переменные хорошо работают в рамках одного файла. Глобально использовать их не так удобно.
Но если нужно просто "подкрасить" — этот проект просто замечательный.
@voischev Дык я и говорю, что почти копия на начальном этапе, только: 1) переименованная 2) вынесенная на отдельный уровень и 3) с проставленными переменными. Всё ради того, чтобы потом легче было манипулировать ею.
@teryaew @voischev Ребят, а подскажите чем плохи глобальные переменные в /design, если туда вынести не только цвета. Есть много примеров, где есть очевидные пропорции элементов относительно друг друга. У нас в компании есть много проектов и мне для дизайна очень удобно манипулировать значениями переменных и мгновенно видеть результат (особенно круто на этапе формирования гайдов). Плюс гайды могут допиливаться и переменные на ключевых параметрах здорово в этом помогают. Я сейчас выношу в переменные еще многие параметры помимо цветов. А потом буду искать пропорции/зависимости, для удобства дальнейшей кастомизации.
Подскажите если где-то есть какие-то косяки с переменными?
Это удобно до тех пор пока у тебя мало файлов.
Когда большой проект и много зависимостей css, а еще css разбит по бем файловой системе по модификаторам элементам и тд. становится грустно. потому что каждому из этих фалойв нужно в зависимости писать зависимость от переменных.
Плюс практика показывается раз от раза что все-таки даже селект основанный на кнопке часто нужно "подстукивать" и эти переменные разрастаются на каждое такое постукивание обычно.
Ну в понимание переменных сильно размазывается по файлам... потом все это очень трудно в кучу собрать.
А еще боль. работаешь над кнопкой, а тут вдруг бац... у селекта что-то поехало :)
Тесты скриншотами конечно тут помогут. Но мы решили отказаться от глобальных переменных. Оставили только для конкретных файлов. И это прям сильно упростило все. И кстати сильно логичнее стало, а то пойди вспомни что там в этой перемернно. Нужно файл с переменными всегда смотреть.
А так — сломал кнопку... за то все остальное точно в порядке! :)
Примерно так. Может у нас просто большой гайд). 2 темы с общими стилями, 4 размера для каждых компонент. 60+ компонент. + тоже самое для мобилки. (5 брейкпоинтов)
@voischev это всё же проблема инструментов, и она решаемая, например так.
Так что я бы её не считал. В остальном согласен :)
нам нужны лайки для топиков!
:+1: отличная работа — посмотрим как это можно втащить в основной код
Продолжаю "потрошить" bem-components. Вытащил все кастомизируемые вещи в переменные. Для того чтоб понимать, какие параметры менять на старте дизайна новой темы.
Пока комменты очень сырые и быдловато написаны (набросал для себя). Выглядит это примерно так - https://github.com/bem-custom/bem-custom-components/blob/custom/design/custom.styl
Поигрался со стилизацией под стиль VK - https://github.com/bem-custom/bem-custom-components/blob/custom/bem-components-vk-theme.jpg
:+1: :+1: :+1:
:+1: :+1: :+1:
:+1: :+1: :+1:
:+1: :+1: :+1:
:hocho: :hocho: :hocho: