Для чего я создал очередную библиотеку, чтобы уменьшить шаблонный код Redux.js
Invite pending
Данный пост — перевод данной статьи
Я работал над новым проектом на React и Redux. Раньше при разработке проектов на React, я работал в одиночку, но в этот раз я был частью команды, где каждый член команды имел некоторый опыт в React и Redux. Проект должен был быть выпущен в продакшн за короткое время.
По началу, мы решили использовать redux-thunk как мидлвер для redux, потому что он очень прост и каждый из нас знал как им пользоваться. Мы разработали RESTful API с конечными точками для каждой таблицы в базе данных. После того как мы поделились с заданиями, каждый из нас приступил к разработке своих модулей. Каждая страничка и модуль приложения получает данные с разных точек нашего API. Некоторые запросы зависят от результата другого запроса, поэтому приходилось связывать запросы в цепочку и передавать необходимые параметры в другую функцию, которая в свою очередь собирает данные с другой таблицы.
Месяц спустя, у нас в проекте было куча экшнов и экшн типов для получения любых данных с нашего API. Кроме того каждый разработчик называл эти функции и константы, как было ему удобно. Другие ребята в команде перед тем как писать новый экшн, должны были рыться в куче экшнов, чтобы не наплодить дубликатов. А если кто-то уже создал экшн и ещё не комитил свой код, а в это время другому человеку потребовалась такая функция и он написал свою, то одному из них приходилось объединить 2 комитнутых экшна.
Где-то в середине нашего процесса разработки, нам поручили дополнительное задание, в котором говорилось, что приложение должно функционировать в оффлайне. Я начал изучать вопрос и очень скоро наткнулся в библиотеку которая называется redux-offline и это оказалось именно тем что нам было нужно. Однако, оно требовало немного другой структуризации экшнов, поэтому нам нужно было переписать большинство наших экшнов, чтобы они сработали с этой библиотекой.
В то время мне начало надоедать структура нашего проекта и проблемы, которые возникают из-за этого. Я начал размышлять об объединение всех экшнов, которые запрашивают данные с сервера в одно место и чтобы каждый из нас мог без труда ими пользоваться.
Я пришел к идее создания библиотеки, которая потребует минимум усилий для получения данных с удаленных источников и положить всю информацию о состоянии запросов и возникших ошибок вне редьюсеров.
Вот наш список требований, составленный мною, для работы с удаленными данными:
Мне удалось создать библиотеку собрав все эти возможности в одну библиотеку с названием redux-data-entity. Я сделал так чтобы отправка запросов работали также как редьюсеры, внутри одной функции, чтобы можно были легко с ориентироваться и изменять. Также, так как нам нужна была поддержка оффлайна, я с интегрировал его с redux-offline и выпустил отдельную библиотеку под названием redux-data-entity-offline
Я работал над новым проектом на React и Redux. Раньше при разработке проектов на React, я работал в одиночку, но в этот раз я был частью команды, где каждый член команды имел некоторый опыт в React и Redux. Проект должен был быть выпущен в продакшн за короткое время.
По началу, мы решили использовать redux-thunk как мидлвер для redux, потому что он очень прост и каждый из нас знал как им пользоваться. Мы разработали RESTful API с конечными точками для каждой таблицы в базе данных. После того как мы поделились с заданиями, каждый из нас приступил к разработке своих модулей. Каждая страничка и модуль приложения получает данные с разных точек нашего API. Некоторые запросы зависят от результата другого запроса, поэтому приходилось связывать запросы в цепочку и передавать необходимые параметры в другую функцию, которая в свою очередь собирает данные с другой таблицы.
Месяц спустя, у нас в проекте было куча экшнов и экшн типов для получения любых данных с нашего API. Кроме того каждый разработчик называл эти функции и константы, как было ему удобно. Другие ребята в команде перед тем как писать новый экшн, должны были рыться в куче экшнов, чтобы не наплодить дубликатов. А если кто-то уже создал экшн и ещё не комитил свой код, а в это время другому человеку потребовалась такая функция и он написал свою, то одному из них приходилось объединить 2 комитнутых экшна.
Где-то в середине нашего процесса разработки, нам поручили дополнительное задание, в котором говорилось, что приложение должно функционировать в оффлайне. Я начал изучать вопрос и очень скоро наткнулся в библиотеку которая называется redux-offline и это оказалось именно тем что нам было нужно. Однако, оно требовало немного другой структуризации экшнов, поэтому нам нужно было переписать большинство наших экшнов, чтобы они сработали с этой библиотекой.
В то время мне начало надоедать структура нашего проекта и проблемы, которые возникают из-за этого. Я начал размышлять об объединение всех экшнов, которые запрашивают данные с сервера в одно место и чтобы каждый из нас мог без труда ими пользоваться.
Я пришел к идее создания библиотеки, которая потребует минимум усилий для получения данных с удаленных источников и положить всю информацию о состоянии запросов и возникших ошибок вне редьюсеров.
Вот наш список требований, составленный мною, для работы с удаленными данными:
- CRUD для одного объекта
- CRUD для нескольких объектов
- Связка запросов
- Фильтрация, сортировка, нумерация страниц и т.д
- Возможность показа отдельных спиннеров для любого запроса
- Оптимистичное UI
Мне удалось создать библиотеку собрав все эти возможности в одну библиотеку с названием redux-data-entity. Я сделал так чтобы отправка запросов работали также как редьюсеры, внутри одной функции, чтобы можно были легко с ориентироваться и изменять. Также, так как нам нужна была поддержка оффлайна, я с интегрировал его с redux-offline и выпустил отдельную библиотеку под названием redux-data-entity-offline