Одна из самых сложных вещей в разработке программного обеспечения: называть вещи. Сюда входят переменные, функции, классы и, конечно же, компоненты.
Чтобы решить эту проблему соответствующим образом, особенно если вы работаете в команде, нет ничего похожего на шаблон, который поможет нам сделать вещи более последовательными и простыми.
В моей команде мы создали шаблон, который помогает нам именовать компоненты пользовательского интерфейса, мы называем его CEV. Я знаю, не очень красиво, но у нас работает. 😄
Схема CEV
CEV означает контекст, элемент и вариант. . Мы называем каждый из них токеном имени компонента.
Подробно ознакомьтесь с каждым из них и его правилами ниже.
Контекст
Каков контекст, к которому этот компонент относится, использует или уважает?
Контекст может быть типом контента, который будет создан, именем родительского элемента или страницы, к которой он принадлежит, или чем-то еще, что поможет вам понять, какова область действия этого компонента.
Обычно это существительное в единственном или множественном числе, а иногда и прилагательное, оканчивающееся на «ble».
Примеры: Post, Posts, Product, Home, Site, Article, Member, Flexible, Collapsable и т. д.
Элемент
Что за элемент пользовательского интерфейса представляет собой компонент?
Название элемента должно давать понять, чего ожидать от этого компонента в пользовательском интерфейсе.
Обычно это существительное в единственном числе, а иногда и во множественном числе.
Примеры: List, Card, Form, Section, Block, Content, Details, Carousel, Accordion, Hero и т. д.
Вариант (необязательно)
Это разновидность другого компонента?
Вариант (или вариант) является необязательным и должен использоваться, когда у вас есть несколько компонентов с одинаковой ролью, но с разными свойствами.
Имя обычно прилагательное.
Пример: Small, Large, Highlighted, Featured, Inverted и т. Д.
Примеры
Вот список примеров использования этого шаблона:
ArticleCardArticleCardSmallArticlesListProductDetailsMembersCarouselQuestionsAccordionTextBlocksStackedNavigationMenuFlexibleContentPageHeroAdvancedHomeHero
Заказ
Этот порядок был определен, чтобы файлы были организованы от большей к меньшей области, причем контекст был больше, а вариация - меньше, поэтому ArticleCardSmall и ArticleCardFeatured будут близки друг к другу.
Исключения и ограничения
Контекст опущен
В большинстве случаев вам потребуются имена Context и Element, тогда как Variant всегда является необязательным, но для некоторых конкретных случаев имя Element может быть достаточно, чтобы легко идентифицировать компонент, поэтому Context можно опустить.
Некоторые примеры: Header, Footer, Sidebar и еще несколько.
Например, для веб-сайта эти имена довольно интуитивно понятны.
Однако, если вы предпочитаете быть более ограниченными в отношении шаблонов и соглашений, вы можете потребовать, чтобы всегда определялся Контекст, используя что-то вроде SiteHeader, AppFooter, ProjectSidebar и т. Д.
Сделайте свой выбор и четко сформулируйте его.
Единственного и множественного числа
Используйте множественное число для Context, когда Element имеет дело с несколькими экземплярами одного и того же Context, например, ArticlesList, ProductsCarousel, QuestionsAccordion и т. Д. используйте единственное число, например ArticleCard, ProductDetail, QuestionBlock и т. д.
Для Element используйте множественное число, если компонент содержит несколько экземпляров этого элемента, например TextColumns, IconBlocks, CollapsableSections и т. Д.
Жетоны из нескольких слов
Бывают случаи, когда вам может потребоваться быть более конкретным и использовать больше слов в токене, возможно, для более организованной работы в вашем проекте.
В качестве примера представьте компонент с именем ArticleFaqAccordionSmall, где ArticleFaq представляет Контекст.
В идеале это недействительное и, возможно, вместо этого переместить одно из слов в вариант, например FaqAccordionArticle (или более подходящее имя). Но если это определенно необходимо для вашего проекта, вы можете либо создать новый префиксный токен (например, Parent Context, или Domain), либо позволить Variant содержат одно или несколько слов, так как это не так сильно повлияет на идентификацию токенов.
Опять же, вы можете адаптировать соглашение к своим потребностям, но всегда лучше, чтобы оно было согласованным.
Вывод
Существует также множество других шаблонов и соглашений об именах, и вы должны выбрать то, что лучше всего подходит для вас, вашей команды и проектов, с которыми вы работаете.
Помните,
Шаблон именования компонентов должен помочь вам сделать именование компонентов более простым и интуитивно понятным для тех, кто именует компонент, для тех, кому нужно искать его в проекте, или для тех, кто нашел его в коде и должен знать, о чем он.
Не существует универсального решения, каждый шаблон / соглашение имеет свои преимущества и недостатки, поэтому выберите тот, который вам и вашей команде будет удобнее.
И хорошее кодирование! 😉
