React
0. Введение
0.1. Термины и определения
0.2. Использованные источники
1. Правила именования файлов
2. Форматирование
3. Использование технологии
3.1. Styled Components
3.1.1. [Не автоматизировано] Использовать для обращения к компоненту класс в качестве селектора
Использовать для обращения к компоненту класс в качестве селектора вместо названия тега.
3.1.2. [Не автоматизировано] Выносить определение атрибутов тэга в отдельную константу
Выносить определение атрибутов тэга в отделюную константу для более лучшего форматирования
``typescript jsx // Плохо export const ButtonRoot = styled.button.attrs<Props>({ type: (props: Props) => props.isSubmit && 'submit' })<Props>
padding: 0.44rem 1.72rem; `;
3.2.2. [Не автоматизировано] Правила именования для обработчиков
Использовать следующий формат для описания обработчика в комментарии: Handler for <действие> on [что-то] [дополнительное описание]
3.2.3. [Не автоматизировано] Порядок в определении свойств
Использовать следующие приоритеты:
Обязательные свойства
Необязательные свойства
Обязательные свойства с callback
Необязательные свойства с callback
В каждом пункте приоритеризация в зависимости от значимости свойства.
3.3. Template
3.3.1. [Не автоматизировано] Вынесение частей шаблона, которая показывается по условию в отдельную функцию
Если у нас есть условие для отрисовки блока и блок занимает больше одной строки, то его необходимо вынести в отдельную функцию.
```typescript jsx // Плохо
{this.props.children} { hasContent && {this.props.title &&{this.props.title}} {this.props.subtitle &&{this.props.subtitle}}{this.props.description} {this.props.icon &&{this.props.icon}} }
b. Не делать дополнительных переносов внутри фигурных скобок для фрагмента, где выводятся вложенные компоненты.
```typescript jsx // Плохо { this.props.items.map(item => ( )) }
4. Правила именования
4.1. [Не автоматизировано] Правила именования презентационных компонентов и компонентов контейнеров
Основная идея в том, чтобы публичные компоненты, которые используются в проекте, имели семантически значимые имена. В данном случае мы имеем в виду, что мы хотим подчеркнуть именно смысл, нежели технические детали, стоящие за реализацией компонента. Как следствие, мы не хотим менять код-потребитель (например, код компонента, который представляет собой конечный экран), если мы изменили технические детали реализации. К техническим деталям относится и привязка компонента к redux или отсутствие таковой.
4.1.1. [Не автоматизировано] У компонента должно быть обычное имя, если мы используем его в коде-потребителе
a. Если компонент не связан с redux, мы должны называть его так, как мы обычно и поступаем в случае именования компонентов, т.е. без дополнительных префиксов и суффиксов:
b. Если компонент использует redux и это компонент, который мы получаем в результате вызова connect
redux'а, используется другими компонентами как семантически значимый, мы должны называть его так, как мы обычно и поступаем в случае именования компонентов, т.е. без дополнительных префиксов и суффиксов:
4.1.2. [Не автоматизировано] Добавлять суффикс для оборачиваемого в connect
компонента
connect
компонентаЕсли мы используем компонент-контейнер в качестве компонента для кода-потребителя, мы должны называть презентационный компонент, т.е. компонент, который оборачивается в connect
, с суффиксом Raw
.
4.2. [Не автоматизировано] Не использовать множественное число в названии компонентов
Имя компонента должно всегда быть в единственном числе, не должно быть множественного.
Last updated