Когда открываю новый проект, одно из первых что смотрю — composables.

Не потому что это какой-то особый критерий. Просто по ним сразу видно, как команда думает о коде. Если composable непонятно что делает, непонятно что возвращает, и название ни о чём — дальше обычно то же самое.

Хороший composable — это когда смотришь на название и уже понятно что он делает. Без чтения исходника. Чёткая ответственность, понятный интерфейс.

Для себя вывел несколько вещей которые помогают не скатиться в кашу:

Название по действию, а не по месту. useUserData — непонятно. useUserProfile или useFetchUser — уже говорит что внутри. Хорошее название отвечает на вопрос «что он делает», а не «где он используется».

Зависимости должны быть ожидаемыми. Использовать стор или роутер внутри composable — нормально. Проблема в другом: если useFormatDate вдруг лезет в useAuthStore — это сюрприз которого никто не ждёт. А useCurrentUser который берёт данные из стора — абсолютно логично, название говорит само за себя.

Возвращай только то что нужно снаружи. Внутренние состояния и вспомогательные флаги которые нужны только самому composable — не должны торчать наружу. Чем меньше публичный интерфейс, тем проще им пользоваться и тем сложнее случайно сломать.

Ещё начал добавлять JSDoc к каждому composable. Буквально пара минут — описываешь что он делает, что принимает, что возвращает. И теперь любой в команде видит это прямо в IDE не открывая файл. Особенно удобно когда composables в общей библиотеке и их много.

Есть простой вопрос который задаю себе: хочется ли мне его переиспользовать? Если нужно сначала залезть внутрь и разобраться — он написан для задачи, не для людей.

И вот это «написан для задачи» — частая история. Быстро вынес логику, назвал как-нибудь, закрыл тикет. Потом другой разработчик не понимает что это, пишет свой. Потом ещё один. Через полгода рядом живут четыре почти одинаковых composable.

Стараюсь писать composable как будто кто-то другой будет им пользоваться.

Когда в проекте тянутся к существующему composable вместо того чтобы писать новый — что-то точно сделано правильно.

А у вас в команде есть соглашения по composables, или каждый пишет как чувствует?