В этой статье я расскажу об одном из способов обеспечения поддержки CSS. Не воспринимайте это как единственно верный способ сделать это, я лишь расскажу, какой подход работает для меня и, как оказалось, хорошо масштабируется и распределяется между несколькими проектами.
Прежде чем углубляться в детали, давайте взглянем на эту картину и посмотрим, как можно создать несколько крупных продуктов пользовательского интерфейса внутри одной организации. Они используют пользовательские компоненты и обмениваются ими между продуктами, чтобы придать им одинаковый внешний вид и повысить производительность при разработке, поскольку проблемы необходимо решать только один раз и их можно повторно использовать в разных продуктах.
Вам также может понравиться: Как справиться с проблемами CSS в IE, когда у вас нет идеи, как их исправить
Что мы имеем здесь? Для простоты у нас есть только одна общая библиотека компонентов и два разных приложения / продукта в организации. У нас есть два общих компонента как компонент даты и компонент планировщика. Они разработаны особым образом, и мы хотели бы дать им настраиваемое поведение, поэтому мы даже создали их.
В настоящее время в приложении A используется только компонент D ate, а в приложении B используются оба компонента.
Какие вещи мы можем сделать, чтобы наши продукты выглядели одинаково? Конечно, стили должны быть разделены! Каждый компонент по умолчанию должен выглядеть одинаково, цвета в разных продуктах должны быть одинаковыми. Что мы можем сделать для этого? Прежде всего, я рекомендую использовать в любом проекте reset.css , вы можете найти много примеров в интернете, это один из них https://meyerweb.com/eric/tools/css/reset/ . После этого мы должны определить все стили / правила для всех компонентов в organisation.(css|less|sass) файле.
После завершения работы остальные компоненты должны содержать изолированные стили, чтобы их можно было повторно использовать в разных проектах и не влиять на поведение настроенных или родительских компонентов. Одним из способов достижения этого является предоставление уникальных идентификаторов. Я приведу пример того, как сделать это с LESS:
МЕНЬШЕ
xxxxxxxxxx
1
.shared-components.custom-date-component {
2
.datepicker__navigation--next {
3
&:hover,
4
&:focus {
5
border-left-color: black;
6
}
7
}
8
9
.datepicker__navigation--previous {
10
&:hover,
11
&:focus {
12
border-right-color: black;
13
}
14
}
15
...
16
}
Это достигается путем создания иерархии стилей, поэтому средства datepicker_navigation--nextбудут применяться только внутри custom-date-componentкомпонента. Поскольку к имени компонента также добавляется имя библиотеки, вероятность дублирования классов близка к нулю.
Для быстрой навигации по стилям лучше использовать одно и то же имя для компонента, имени файла и имени класса CSS.
JavaScript
xxxxxxxxxx
1
// custom-date-component.js
2
import './custom-date-component.less';
3
export const CustomDateComponent = () => <div/>;
МЕНЬШЕ
xxxxxxxxxx
1
.custom-date-component {
2
...
3
}
Если вы начнете связываться с именами, вы окажетесь в ситуации, когда вам придется делать ненужные переходы, чтобы выяснить, какое имя класса относится к какому компоненту. Даже если вы используете некоторые общие стили для компонентов, лучше придерживайтесь той же стратегии и найдите общее имя класса внутри.
МЕНЬШЕ
xxxxxxxxxx
1
.custom-date-component {
2
.some-shared-class-name;
3
}
4
Теперь давайте представим , что вам нужно добавить ту же страницу администратора для приложения A , который уже существует для приложения B . Соблюдение одной и той же стратегии внутри приложения и сохранение каждого блока в изолированном стиле облегчит совместное использование компонентов.
Что делать, если компонент Date в приложении B требует дополнительного стиля - вы сохраняете это переопределение внутри имени .application-b класса.
xxxxxxxxxx
1
.application-b {
2
.custom-date-component {
3
color: red;
4
}
5
}
В этом случае все стили из и на вершине , что переопределяется только для приложения B . Даже когда страница администратора будет добавлена в приложение. Стили будут в форме, так как только красный цвет будет применяться к приложению B. Если вам нужно сделать это для страницы администратора, не связанной с приложением, то вы переопределяете значение not . .custom-date-component color .admin-page .application-b
Примечание. Одна распространенная ошибка, которую я всегда вижу, заключается в том, чтобы все такие переопределения относились к компоненту, не выше иерархии, не ниже. Если вы делаете это:
МЕНЬШЕ
1
.admin-page {
2
.custom-date-component {
3
color: red;
4
}
5
}
Храните его внутри компонента страницы администратора , а не в глобальном проекте приложения B или в каком-либо родительском компоненте. В противном случае вы начнете терять контроль над тем, что происходит откуда и не будет повторного использования. Так как просто нахождение того же компонента в другом проекте потребует копания, поиска недостающих стилей, которые должны быть выбраны из других мест.
Резюме самых важных правил:
- Храните все глобальные стили в отдельном файле.
- Держите стили компонентов (страниц, макетов) постоянно изолированно.
- Сохраняйте одно и то же имя в имени файла JavaScript, имени компонента, имени файла стиля и имени класса стиля.
Эти простые правила позволят эффективно поддерживать и масштабировать вашу систему. Как это будет иметь предсказуемое поведение, что супер важно в масштабе. Переход к нужному месту в коде с минимальными усилиями, который будет играть большую роль в вашей общей производительности. Когда приложение растет, трудно запомнить все детали, и вы постоянно перемещаетесь по коду.
Вы можете подумать, это супер просто! Да, это! Но вы не можете себе представить, как сложно держать всех на одной странице и следить за тем, чтобы процесс следовал за ней. Относитесь серьезно к процессу рассмотрения запросов на извлечение и обучайте новых людей, когда они присоединяются к проекту.
Ждем ваших комментариев и отзывов. Не стесняйтесь также поделиться своим стилем работы со стилями в большом приложении.