Оптимизация подключения REST API для React приложений
Основная идея
Инструкция направлена на оптимизацию способа обмена данными между клиентом и сервером.
При написании компонентов, большинство разработчиков нагружают свой код излишней логикой в процессе подключения REST API. В итоге компонент в большей степени выполняет роль прокси объекта, и становится тяжело читаемым, трудно тестируемым, что особо пагубно влияет на разработку в команде. Основная задача инструкции направлена на обеспечение более декларативного подхода. Ниже представлены два варианта: код оптимального подключения REST API и классический способ для одного и того же компонента.
В первом случае мы используем уникальный объект «API», который сам выполняет все за нас, обеспечивает более полиморфный подход и переносит логику в общий модуль. Во втором примере присутствует большая логическая нагрузка на компонент.
Далее будет рассмотрена реализация данного объекта с использованием redux и нативных возможностей javascript. Информация актуальна для React и React-Native приложений.
Однако существует множество других шаблонов обмена бизнес данными между клиентом и сервером с использованием сторонних библиотек. Некоторые из них:
Предполагается, что на данном этапе уже существуют конкретные эндпоинты для запроса на сервер. Требуется создать отдельный модуль с названием API. Он будет содержать конструктор класса, экспорт его экземпляра, методы для взаимодействия с сервером и состоянием приложения. Пример:
Далее требуется наполнить класс асинхронными методами для взаимодействия с сервером.
В данном примере добавлены два метода «getCartList» (получение списка данных) и «addProduct» (добавление данных на сервер). В результате вызова оба метода возвращают Promise, которые при выполнении возвращает ответ сервера в JSON формате.
Далее требуется добавить взаимодействие с состоянием приложения через redux store. Предполагается, что уже подключен redux \ modx (В примере redux). Добавим dispatch метод, и будем его вызывать внутри наших методов (можно вызвать dispatch до запроса для мгновенного обновления состояния, либо после запроса, когда требуется использовать данные из ответа сервера.)
В результате мы можем использовать наш класс внутри компонентов множества компонентов. При модификации api запроса потребуется изменить лишь логику внутри одного из методов класса внутри нашего модуля. Пример использования:
При этом мы можем вызывать методы класса с использованием своих хуков, например:
В момент отрисовки компонента, происходит вызов метода API и происходи загрузка данных и смена состояния. Данный подход очень напоминает хуки graphql-apollo.
Благодаря данному подходу мы избавляемся от большой логической нагрузки и уменьшаем зону ответственности при подключении и модификации api. Сплошными стрелками на схеме отмечена основная логическая нагрузка при подключении.
Для защиты типов и поддержки кода добавим типизацию с применением typescript. Такой подход позволит получить доступ к результатам ответа сервера без документации к API сервера спустя длительное время работы с кодом.
Я извиняюсь как человек, пишущий в ооп стиле и пользующийся мобиксом, вот этот трэш, подписанный как "CLASSIC OLD", его реально пишут? Его там тимлиды смотрят на код ревью, говорят что все норм и аппрувят? Просто мне казалось, в редаксе запросы к сервисам принято хотя бы в экшены прятать.
привет,
Пример с использованием экшенов я особо не упоминал, тк это в большей степени напоминает сагу, где происходит практически то же самое , но через прослойку эффектов.
Если посмотреть ≈90% гайдов с ютуба, все они рекомендуют именно такой способ "classic".
Сам я рекомендую использовать данный способ из статьи только при не большом количестве эндпоинтов, когда выгоднее отказаться от включения библиотеки
Степ, пости такое лучше на хабр, тутошний народ гораздо больше любит когда кого-то Яндекс еда обманула на гамбургер
Я извиняюсь как человек, пишущий в ооп стиле и пользующийся мобиксом, вот этот трэш, подписанный как "CLASSIC OLD", его реально пишут? Его там тимлиды смотрят на код ревью, говорят что все норм и аппрувят? Просто мне казалось, в редаксе запросы к сервисам принято хотя бы в экшены прятать.
привет,
Пример с использованием экшенов я особо не упоминал, тк это в большей степени напоминает сагу, где происходит практически то же самое , но через прослойку эффектов.
Если посмотреть ≈90% гайдов с ютуба, все они рекомендуют именно такой способ "classic".
Сам я рекомендую использовать данный способ из статьи только при не большом количестве эндпоинтов, когда выгоднее отказаться от включения библиотеки
Привет, дай наводку, где мы с тобой виделись)
Возможно, это мой первый опыт,
появился повод попробовать для конкурса
🖐️
А есть пример проекта на GitHub? Хотелось бы посмотреть это в действии.