# best practics

## Сodestyle
Предпочитаемые настройки prettier для форматирования кода:

---
Последовательность импортов

Чтобы хорошо ориентироваться в своих же дебрях, нужно знать где что находиться на уровне миникарты

Последовательность:

1. Установленные библиотеки
2. Кастомные компоненты
3. Утилиты
4. Ассеты
5. Графика
6. Стили

Хорошо:


Плохо:


Внутри функционального компонента тоже должен быть порядок, иначе в какой то момент будешь путаться и не понимать где state, который почему-то объявляется прямо перед return

Структура компонента:
1. State, ref, navigator, selector и т.д.
1. Функции для работы (если нужны в рамках данного компонента)
1. useEffect
1. return jsx


Префиксы scss-переменных должны совпадать с используемым свойством


Деструктуризация компонентов
Не растягивать компонент в 500 строк кода, обязательно разделять компонент на логические составляющие, не превышающие 150 строк.

В рамках одного компонента/модуля/класса описывать только схожий функционал, который объединен смыслом

Стараться отделять логический функционал от компонента, т.е. не выстраивать десятки функций внутри компонента, тем самым усложняя читаемость и логику. К тому же, вполне вероятно что этот функционал можно будет переиспользовать в других схожих компонентах.

По возможности, а желательно не следует лезть напрямую в dom, реакт этого не любит и сами разрабы об этом пишут и не важно, меняешь ли ты св-ва или стили в элементе, если уж надо, то для этого есть хук useRef, хотя у него есть ещё и другие применения.

Если что то можно сделать через css - делай. Не стоить уповать на функциональность реакта, ведь в самый неподходящий момент всё может зафейлить ререндер

Использовать кастомные хуки. Их не зря придумали и часть функционала компонентов можно здорово уместить в хук, который к тому же будет более реиспользуемым, чем статическая функция в классе

Если есть не меняющиеся объекты/массивы, лучше вынести это в ассеты, либо же использовать мемоизацию.

Если мы в компоненте используем фильтрации, сортировки или же расчёты которые могут опять повториться, то лучше всего мемоизировать это.

На небольшое действие (типо открытие модалки или передача пары пропсов наверх) отдавать предпочтение useContext, а не редаксу, из за того, что редакс влияет на глобальное состояние приложения, он тупо увеличит кол-во рендеров

Но и useContext нужно использовать с умом, ибо при изменении состояния, он сделает ререндер всем компонентам, которые в него обёрнуты

Использовать layout. Если на сайте должны быть постояные блоки (header, footer, navbar), то стоит это вынести в отдельный слой, а все внутренние компоненты передавать через children, тем самым реиспользуя код.

Если в компоненте больше 4 пропсов, то лучше соединить в один объект

Так не надо:


Надо так:


Не мутировать переменные напрямую, а делать копии, иначе потом будешь удивляться: “а почему в моём моем исходном массиве всё удалилось?”

Типизация: использовать приведение типов js, чтобы потом не ломать голову, мол: “Какого хрена тут строка, а не число?”

Всегда следует незамедлительно фиксить ошибки типизации, чтобы не было как на скрине ниже. Если понадобиться экстренно закинуть проект в докер, то он нормально не заработает.
Проблем с исправлением обычно не возникает, т.к. ts нормально подсказывает в чём именно проблема.

Работа с интерфейсами.
Если интерсфейс можно переиспользовать или у него большое кол-во параметров, рекомендуется вынести его в файл interface.tsx.
Иначе можно оставить его чуть выше компонента.
Именовать интерфейс (если он относиться к конкретному компоненту), стоит через название компонента с постфиксом Int.

Проверка на существование ключа в объекте делать через hasOwnProperty, а не прямое условие, ибо в ключе может прийти false, null, 0 и т.д.


После успешно завершённой отладки кода следует удалять за собой console.log функции