первое, что на ум пришло — open-source react компоненты.
Конкретный пример из проектов. Создавали компонент для авторизации. Изначально он получился более ориентированным под задачи первого проекта. Для следующего проекта требовалась та же форма, но с некоторыми дополнениями или что-то было лишнее. В результате, компонент стал более абстрактным от изначального варианта, появилась дополнительная конфигурация, компонент был вынесен в отдельный репозиторий.
Речь идет о процессе разработки компонентов для повторного использования. Такие компоненты разрабатываются итеративно, так как все возможные варианты использования изначально неизвестны :) Часто компонент нужно изменить или нарушить backward compatibility для его использования в другом проекте. Современные фронтенд фреймворки ориентированы на компонентную разработку, каждый имеет свои плюсы и минусы. Но процесс обобщения компонентов не зависит от фреймворка.
По нашему опыту, самый частый случай inner source — компоненты завязанные на внутренние сервисы либо более сложные компоненты, часто состоящих из нескольких базовых компонентов и надстроек к ним.
Из примеров, что первое на ум пришло: react обвертки для плееров, компонентов рекламы, нам конкретно пришлось сделать свой внутренний react-picture в виду способа хранения изображений. У walmart из примеров еще есть навигация, компоненты со страницы пользователя. Самому интересно было б услышать примеры от других людей.
Повторно использовать какие-нибудь шаблоны или Higher order components пока не доводилось, так как не было пока случая, когда это целесообразно.
Точно прочитали? :)
От себя скажу, что подход из статьи хорошо подходит, когда нужно поддерживать и разрабатывать несколько похожих проектов одновременно. У нас в компании стоит похожая задача, и подход Walmart хорошо решает множество вопросов. Так что, в идеале, новый проект с похожей структурой и компонентами требует меньше усилий на разворачивание, разработку и поддержку.
На мой взгляд, компоненты можно четко разделить на базовые, которые могут использоваться в любом проекте, например — react-select, react-modal и т.д., и специфичные для определенного типа проектов, как, например, упомянутая форма оплаты. В рамках проектов walmart ее структура и бизнес логика не меняется, меняется внешний вид.
Собственно, базовые компоненты имеет смысл open-source-ить, специфичные — inner-source-ить.
Делать компоненты, которые можно повторно использовать — довольно затратное дело, должны быть очевидные причины для инвестирования усилий в это. Если проекты небольшие, разные, нет обязательств по их поддержке, то можно ограничиться лишь повторным использованием базовых компонентов. И это нормально.
Да, скорее всего многое из Electrode не всем подойдет, кто-то предпочитает npm scripts gulp-у (я же поменял свое мнение в пользу gulp после Electrode), другие методы вытягивания данных и т.д. От себя могу сказать, что решения, которые ребята предложили действительно оригинальные, особенно в плане повторного использования react компонентов — это одна из главных задач в команде, где я работаю. Не в восторге от нашего текущего решения. Но с помощью Archetypes и Explorer это можно сделать на порядок лучше. Поэтому мы собираемся попробовать Electrode на следующем проекте. Можно использовать просто часть инструментов, которые они предлагают.
Не подумайте, что я придираюсь, но на хабре полно статей «качество кода vs. скорость» (в других хабах). Как программист, знаю, что ситуация «win-win» возникает только при определённых условиях (в долгосрочной перспективе, при отсутствии кардинальных изменений в ТЗ и т.д.).
Скорость можно потерять только при переходе на SASS + Compass и настройке окружения, CSS файл при переименовании в .scss будет компилироваться без проблем. По сути, этот еще тот же CSS, только теперь появляется много возможностей как: выстроить необходимую структуру папок, манипуляции с изображениями, Grids где хотите и как хотите, снижение дубликации кода и тд. А за качеством кода нужно чтобы кто-то следил и знал, что это такое и как добиться.
Это всё круто. Но в жизни так выходит, что на проекте, который уже много лет в топ-500 alexa.com, до сих пор атмосфера бутстрэппинга. Правки в дизайн вносятся в таком режиме, когда некогда думать о высоких материях стандартах. Но ок, попробую поднять этот вопрос. Пойду поищу грамотного фронтенд лида. :)
вспомнил поговорку в тему — «Точить некогда, мне пилить надо». А в вообще, понимаю :) Когда сроки горят — не до этого. Лучший эффект, конечно, когда все настроено в начале проекта. Удачи в поисках!
Для меня показатель эффективности, это когда можно с инструментом написать более качественный код и быстрее, чем без него. SASS + Compass автоматизируют рутинные задачи и имеют много полезных хелперов. Зачем изобретать что-то заново, если оно уже есть и протестированно сообществом? Можно, конечно, и c помощью чистого CSS умудриться написать приличный проект, но Вы, скорее всего, будете каким-нибудь образом пытаться синтезировать то, что уже есть в SASS + Compass. И огромный минус чистого CSS — дубликация кода со всеми вытекающими последствиями. На более менее приличном проекте всегда есть смысл использовать CSS препроцессор.
То, что код чище — понятно. Но времени на создание и особенно поддержку этой чистоты — такое ощущение, что не меньше, чем писали бы на простом CSS.
Задокументированные стандарты по производительности и архитектуре ваших стилей + настроенное окружение + грамотный фронтенд лид — это что обычно нужно для поддержки чистоты и целостности кода.
«Задокументированные стандарты по производительности и архитектуре в ваших стилях» — нужно учитывать размеры/сложность проекта, целевые браузеры/устройства. Хороший пример для респонсив сайтов: github.com/Snugug/north. Если уже есть стандарты на уровне проекта/компании — хорошо, если нету — хороший шанс начать и по-тихоньку выстроить сообщество внутри компании.
«Настроенное окружение» — зависит от проекта/размера команды. чем больше команда, тем больше Вам нужно обезопасить себя от головняка, автоматизировать рутинные процессы, настроить grunt + JS/CSS lint (пускай код стайл проверяется автоматически), minifier и concat. Очень приятно ощущать разницу до автоматизации и после.
«грамотный фронтенд лид» — который в состоянии поднять и настроить окружение и процесс и будет следить за соблюдением стандартов.
К сожалению, без этих моментов проект ждет довольно хаотичное состояние.
Спасибо за коммент. Соглашусь, пожалуй, лишь с пункстами 2, 6.
1. Работаю с Compass тоже на крупном проекте, не сталкивался с проблемой производительности. Основная нагрузка приходиться на генерацию спрайтов, но файлы спрайтов обновляются только при добавлении нового изображения. Обработка scss происходит быстро, хватает времени перезагрузить страницу, а при использовании LiveReload вообще не волнует. Какой объем стилей?
3. Лучше все-таки все инклуды держать в _base.scss или в одном общем файле, это проблема организации кода.
4. Интересно, еще не сталкиывался с такой проблемой, но возможно это поможет её решить.
5. Что мешает создать еще один styles_2nd_part.scss, что сгенерирует дополнительный css файл, и подключить его? В нем соответсвенно подключить общие файлы с инклудами.
7. Следуйте правилу вложенности селекторов не больше 3-го уровня, @extеnd — не всегда лучший способ наследования, можно использовать сайлент селекторы или миксины. Они предоставляют меньше зависимостей и переопределений.
8. Не хочется запоминать миксины — пишите как привыкли. Как раз запомнить необходимые миксины и использовать их — лучшее вложение времени, чем писать одни и те же правила много раз.
9. Формируйте свою архитекуру файлов и подключайте их как Вам удобно.
Compass — не панацея и не для каждого проекта, в нем есть свои минусы, по мне так они незначительные. Но плюсов его использования я вижу несомненно больше.
Конкретный пример из проектов. Создавали компонент для авторизации. Изначально он получился более ориентированным под задачи первого проекта. Для следующего проекта требовалась та же форма, но с некоторыми дополнениями или что-то было лишнее. В результате, компонент стал более абстрактным от изначального варианта, появилась дополнительная конфигурация, компонент был вынесен в отдельный репозиторий.
Из примеров, что первое на ум пришло: react обвертки для плееров, компонентов рекламы, нам конкретно пришлось сделать свой внутренний react-picture в виду способа хранения изображений. У walmart из примеров еще есть навигация, компоненты со страницы пользователя. Самому интересно было б услышать примеры от других людей.
Повторно использовать какие-нибудь шаблоны или Higher order components пока не доводилось, так как не было пока случая, когда это целесообразно.
От себя скажу, что подход из статьи хорошо подходит, когда нужно поддерживать и разрабатывать несколько похожих проектов одновременно. У нас в компании стоит похожая задача, и подход Walmart хорошо решает множество вопросов. Так что, в идеале, новый проект с похожей структурой и компонентами требует меньше усилий на разворачивание, разработку и поддержку.
На мой взгляд, компоненты можно четко разделить на базовые, которые могут использоваться в любом проекте, например — react-select, react-modal и т.д., и специфичные для определенного типа проектов, как, например, упомянутая форма оплаты. В рамках проектов walmart ее структура и бизнес логика не меняется, меняется внешний вид.
Собственно, базовые компоненты имеет смысл open-source-ить, специфичные — inner-source-ить.
Делать компоненты, которые можно повторно использовать — довольно затратное дело, должны быть очевидные причины для инвестирования усилий в это. Если проекты небольшие, разные, нет обязательств по их поддержке, то можно ограничиться лишь повторным использованием базовых компонентов. И это нормально.
Скорость можно потерять только при переходе на SASS + Compass и настройке окружения, CSS файл при переименовании в .scss будет компилироваться без проблем. По сути, этот еще тот же CSS, только теперь появляется много возможностей как: выстроить необходимую структуру папок, манипуляции с изображениями, Grids где хотите и как хотите, снижение дубликации кода и тд. А за качеством кода нужно чтобы кто-то следил и знал, что это такое и как добиться.
вспомнил поговорку в тему — «Точить некогда, мне пилить надо». А в вообще, понимаю :) Когда сроки горят — не до этого. Лучший эффект, конечно, когда все настроено в начале проекта. Удачи в поисках!
Для меня показатель эффективности, это когда можно с инструментом написать более качественный код и быстрее, чем без него. SASS + Compass автоматизируют рутинные задачи и имеют много полезных хелперов. Зачем изобретать что-то заново, если оно уже есть и протестированно сообществом? Можно, конечно, и c помощью чистого CSS умудриться написать приличный проект, но Вы, скорее всего, будете каким-нибудь образом пытаться синтезировать то, что уже есть в SASS + Compass. И огромный минус чистого CSS — дубликация кода со всеми вытекающими последствиями. На более менее приличном проекте всегда есть смысл использовать CSS препроцессор.
Задокументированные стандарты по производительности и архитектуре ваших стилей + настроенное окружение + грамотный фронтенд лид — это что обычно нужно для поддержки чистоты и целостности кода.
«Задокументированные стандарты по производительности и архитектуре в ваших стилях» — нужно учитывать размеры/сложность проекта, целевые браузеры/устройства. Хороший пример для респонсив сайтов: github.com/Snugug/north. Если уже есть стандарты на уровне проекта/компании — хорошо, если нету — хороший шанс начать и по-тихоньку выстроить сообщество внутри компании.
«Настроенное окружение» — зависит от проекта/размера команды. чем больше команда, тем больше Вам нужно обезопасить себя от головняка, автоматизировать рутинные процессы, настроить grunt + JS/CSS lint (пускай код стайл проверяется автоматически), minifier и concat. Очень приятно ощущать разницу до автоматизации и после.
«грамотный фронтенд лид» — который в состоянии поднять и настроить окружение и процесс и будет следить за соблюдением стандартов.
К сожалению, без этих моментов проект ждет довольно хаотичное состояние.
1. Работаю с Compass тоже на крупном проекте, не сталкивался с проблемой производительности. Основная нагрузка приходиться на генерацию спрайтов, но файлы спрайтов обновляются только при добавлении нового изображения. Обработка scss происходит быстро, хватает времени перезагрузить страницу, а при использовании LiveReload вообще не волнует. Какой объем стилей?
3. Лучше все-таки все инклуды держать в _base.scss или в одном общем файле, это проблема организации кода.
4. Интересно, еще не сталкиывался с такой проблемой, но возможно это поможет её решить.
5. Что мешает создать еще один styles_2nd_part.scss, что сгенерирует дополнительный css файл, и подключить его? В нем соответсвенно подключить общие файлы с инклудами.
7. Следуйте правилу вложенности селекторов не больше 3-го уровня,
@extеnd— не всегда лучший способ наследования, можно использовать сайлент селекторы или миксины. Они предоставляют меньше зависимостей и переопределений.8. Не хочется запоминать миксины — пишите как привыкли. Как раз запомнить необходимые миксины и использовать их — лучшее вложение времени, чем писать одни и те же правила много раз.
9. Формируйте свою архитекуру файлов и подключайте их как Вам удобно.
Compass — не панацея и не для каждого проекта, в нем есть свои минусы, по мне так они незначительные. Но плюсов его использования я вижу несомненно больше.