Инструкция направлена на оптимизацию способа обмена данными между клиентом и сервером.
При написании компонентов, большинство разработчиков нагружают свой код излишней логикой в процессе подключения REST API. В итоге компонент в большей степени выполняет роль прокси объекта, и становится тяжело читаемым, трудно тестируемым, что особо пагубно влияет на разработку в команде. Основная задача инструкции направлена на обеспечение более декларативного подхода. Ниже представлены два варианта: код оптимального подключения REST API и классический способ для одного и того же компонента.
В первом случае мы используем уникальный объект «API», который сам выполняет все за нас, обеспечивает более полиморфный подход и переносит логику в общий модуль. Во втором примере присутствует большая логическая нагрузка на компонент.
Далее будет рассмотрена реализация данного объекта с использованием redux и нативных возможностей javascript. Информация актуальна для React и React-Native приложений.
Предполагается, что на данном этапе уже существуют конкретные эндпоинты для запроса на сервер. Требуется создать отдельный модуль с названием API. Он будет содержать конструктор класса, экспорт его экземпляра, методы для взаимодействия с сервером и состоянием приложения. Пример:
//API create
class API{
// ... methods ...
}
export default new API()
Далее требуется наполнить класс асинхронными методами для взаимодействия с сервером.
В данном примере добавлены два метода «getCartList» (получение списка данных) и «addProduct» (добавление данных на сервер). В результате вызова оба метода возвращают Promise, которые при выполнении возвращает ответ сервера в JSON формате.
Далее требуется добавить взаимодействие с состоянием приложения через redux store. Предполагается, что уже подключен redux \ modx (В примере redux). Добавим dispatch метод, и будем его вызывать внутри наших методов (можно вызвать dispatch до запроса для мгновенного обновления состояния, либо после запроса, когда требуется использовать данные из ответа сервера.)
//dispatching in API
import store from './stroe'
import {setCartAction, addProductById} from './actions'
class API{
location = 'http://server.com/'
dispatch(action){
store.dispatch(action)
}
//GET /list
async getCartList(){
const result = await fetch(this.location+'list').then(res=>res.json())
//dispatch after request
this.dispatch(setCartAction(result))
return result
}
//POST /:id
async addProduct({product_id}){
//dispatch before request
this.dispatch(addProductById(product_id))
return await fetch(this.location + product_id, {method:'post'}).then(res=>res.json())
}
}
export default new API()
В результате получается довольно читабельный и последовательный алгоритм (на схеме справа) [email protected]
В результате мы можем использовать наш класс внутри компонентов множества компонентов. При модификации api запроса потребуется изменить лишь логику внутри одного из методов класса внутри нашего модуля. Пример использования:
Благодаря такому подходу контекст тела компонента становится чище и лучше, подобно тому, как мы создаем собственные хуки для переноса логики. [email protected]
При этом мы можем вызывать методы класса с использованием своих хуков, например:
В момент отрисовки компонента, происходит вызов метода API и происходи загрузка данных и смена состояния. Данный подход очень напоминает хуки graphql-apollo.
Благодаря данному подходу мы избавляемся от большой логической нагрузки и уменьшаем зону ответственности при подключении и модификации api. Сплошными стрелками на схеме отмечена основная логическая нагрузка при подключении.
Данный паттерн можно модифицировать благодаря использованию библиотеки axios . Основная польза от использования библиотеки:
Доступ к Interceptors (перехват запросов и ответов через обработчик)
create метод для создания универсального интерфейса запросов.
Оптимизация обработки ответа сервера для text и json формата.
Удобная типизация.
Пример класса API с использованием основных кейсов библиотеки
//axios API pattern
const server = axios.create({
baseURL: 'http://server.com',
})
class API {
constructor() {
//INITIAL REQ AND RES OBSERVE
server.interceptors.request.use((req) => {
this.dispatch(setLoadingAction(true))
return req
})
server.interceptors.response.use((res) => {
this.dispatch(setLoadingAction(false))
return res
})
}
dispatch(action){
store.dispatch(action)
}
getHeaderWithToken(){
return {headers: {token: store.getState().token}}
}
setError(e){
console.warn(e)
dispatch(setErrorAction(e))
}
async getUserDataAndSet(){
const result = await server.get( '/user/info', this.getHeaderWithToken())
.catch((e) => this.setError(e))
this.dispatch(setUserAction(result.data.user))
return result
}
}
axios предоставляет удобный интерфейс для перехвата события запроса и\или ответа. При этом можно модифицировать объекты данных. Это удобно, когда требуется изменить состояние загрузки приложения внутри redux при каждом запросе. [email protected]
Для защиты типов и поддержки кода добавим типизацию с применением typescript. Такой подход позволит получить доступ к результатам ответа сервера без документации к API сервера спустя длительное время работы с кодом.
Я извиняюсь как человек, пишущий в ооп стиле и пользующийся мобиксом, вот этот трэш, подписанный как "CLASSIC OLD", его реально пишут? Его там тимлиды смотрят на код ревью, говорят что все норм и аппрувят? Просто мне казалось, в редаксе запросы к сервисам принято хотя бы в экшены прятать.
привет,
Пример с использованием экшенов я особо не упоминал, тк это в большей степени напоминает сагу, где происходит практически то же самое , но через прослойку эффектов.
Если посмотреть ≈90% гайдов с ютуба, все они рекомендуют именно такой способ "classic".
Сам я рекомендую использовать данный способ из статьи только при не большом количестве эндпоинтов, когда выгоднее отказаться от включения библиотеки
Степ, пости такое лучше на хабр, тутошний народ гораздо больше любит когда кого-то Яндекс еда обманула на гамбургер
Я извиняюсь как человек, пишущий в ооп стиле и пользующийся мобиксом, вот этот трэш, подписанный как "CLASSIC OLD", его реально пишут? Его там тимлиды смотрят на код ревью, говорят что все норм и аппрувят? Просто мне казалось, в редаксе запросы к сервисам принято хотя бы в экшены прятать.
привет,
Пример с использованием экшенов я особо не упоминал, тк это в большей степени напоминает сагу, где происходит практически то же самое , но через прослойку эффектов.
Если посмотреть ≈90% гайдов с ютуба, все они рекомендуют именно такой способ "classic".
Сам я рекомендую использовать данный способ из статьи только при не большом количестве эндпоинтов, когда выгоднее отказаться от включения библиотеки
Привет, дай наводку, где мы с тобой виделись)
Возможно, это мой первый опыт,
появился повод попробовать для конкурса
🖐️
А есть пример проекта на GitHub? Хотелось бы посмотреть это в действии.