Где и как лучше хранить логику работы с api в React приложении?

Question

[Gimir]

Доброго времени суток! Задался вопросом, как и где лучше хранить логику работы с api в проекте.
Видел разные примеры: Создание классов для конкретных эндпоинтов со всеми нужными методами, и хранение их в отдельном файле; cоздание функций для методов эндпоинта, которые возвращают промисы, и хранение в разных файлах для разных эндпоинтов и т.д.

А как это вообще лучше всего делать в плане масштабируемости и переиспользования?
Может есть ссылки на статьи или на примеры хорошо организованного проекта?

Comments

[antsam]

Для ответа на вопрос важно понимать где состояние собираетесь хранить? В redux, mobx или в стейте реакт компонента?

[Gimir]

antsam, ну на данный момент проект написан так, что состояние хранится в локальном стейте компонентов. Причем есть редакс, но он используется только для состояния авторизации ‍♂️, но это долго рассказывать) в общем, дела с редаксом тут совсем плохи, по этому я решил не нарушать общую структуру приложения а делать как уже сделано, только чуть лучше.
Вообще, мне нравится редакс, но вот хранить всю логику работы с сервером в мидлверах... создается какое-то чувство скованности что-ли, но могу ошибаться.
В общем, логику на данный момент храню в хуках и в хук компонентах (там где требуется много логики, например в редакторах). А сервисы для работы с каждым эндпойнтом храню в отдельном месте.

Answer 1

[Сергей Сунцев]

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

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

Answer 2

[antsam]

Много есть вариантов которые вполне можно использовать. Однозначно правильного и всеми принятого решения нет.
Если проект на редаксе, то делают через мидлвары. Или thunk, или saga - что тоже мидлвары.
Если вопрос чисто по апи, то посмотрите в сторону Apollo.
Меня ни один вариант не устраивал. У меня свой - непопулярный.
Я в своем последнем проекте провел жирную линию между UI и бизнесс логикой. Готовил статью по этому поводу, но все руки не дойдут ее закончить. Хоть тут отпишусь )

Если в кратце то начиная с корневого компонента я разделил все на актеры и UI. Ветка с актерами отвечает за бизнесс логику, а ветка с UI только за отрисовку (то для чего реакт и был создан)
У этих двух слоев общий стор (например с помощью редакса).
UI слой берет данные из стора и по действиям пользователя меняет состояние.
Слой актеров смотрит на изменение состояния и выполняет соответсвующие изменения в сторе. В том числе делает запросы на сервер и сохраняет результат в сторе.

Но т.к. я люблю максимально все делить ня слои, то все методы API я вынес еще в один слой и прокинул их в актеры через контекст.

Такой подход с актерами очень удобен в отличии от редакс мидлвар, т.к. можно использовать функционал реакта, а именно хуки.
А чтобы не перепутать актеров с UI компонентами я их пишу немного в другом стиле - без jsx и оборачиваю в специально для этого созданный модуль react-ghost (типа "призрак")