Файловая структура проекта

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

В некоторых проектах, что прислали на ревью, в файловой структуре бывало достаточно тяжело разобраться. Тут и pages внутри components, и другие чудеса.

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

Также стоит руководствоваться просто логикой. Лично для меня не до конца понятно, когда в папку utils складывают компоненты и валидаторы, а константы в папку services

Компоненты я бы сложил к компонентам, даже если они утилитарные (пример на фото), а валидаторы в сервисы, хотя момент всё таки спорный. Лично я бы сделал что-то типа ValidatorService и разделил бы его на два дочерних сервиса: InputValidator и ModelValidator

Тут InputValidator отвечал бы, очевидно, за ввод, а ModelValidator для валидации моделей, например, валидации payload’a из ответа апишки.

Вызов самого валидатора был бы следующий:

 ValidatorService.InputValidator.email(email)

Я люблю такие оргструктуры, это мой код стайл. Кому-то он покажется странным, но его плюсы очевидны:

1. Строгая иерархичность и однозначность расположения валидаторов
2. Простой поиск того, что тебе нужно
3. Красивые импорты
4. Простое управление публичным интерфейсом сущности

Архитектурная методология Feature Slices Design

@prog_way_blog — #review