Мы хотим создать пакет, который позволит нам избавиться от постоянного создания однотипных reducer'ов и action creator'ов для каждой модели, получаемой по API.
Первая часть — вот эта вот статья. В ней мы создали конфиг для нашего будущего пакета и выяснили, что он должен содержать action creator, middleware и reducer. Приступим к разработке!
Action Creator
Начнем мы с самого простого — action creator'а. Тут наш вклад будет минимальным — нам нужно просто написать традиционный action creator для redux-api-middleware с учетом нашего конфига.
Для получения юзеров он должен выглядеть приблизительно так:
import {CALL_API} from 'redux-api-middleware'; const get = () => ({ [CALL_API]: { endpoint: 'mysite.com/api/users', method: 'GET', types: ['USERS_GET', 'USERS_SUCCESS', 'USERS_FAILURE'] } });
В action можно добавить еще headers, credentials. Если запрос успешен, то мы получаем USERS_SUCCESS, и у него в action.payload лежат полученные по API данные. Если произошла ошибка, — получаем USERS_FAILURE, у которого в action.errors лежат ошибки. Все это подробно описано в документации.
В дальнейшем, для простоты рассуждений, будем считать, что данные в payload уже нормализованы. Нас интересует, как можно модернизировать наш creator для получения всех сущностей. Все довольно просто: для того, чтоб возвращать нужные сущности, передаем в creator название этой сущности:
import {CALL_API} from 'redux-api-middleware'; const initGet = (api) => (entity) => ({ [CALL_API]: { endpoint: api[entity].endpoint, // endpoint мы будем брать из конфига method: 'GET', types: api[entity].types // и actions мы будем брать из конфига } });
Еще необходимо добавить фильтрацию ответа сервера по GET-параметрам, чтоб мы могли ходить только за нужными данными и не тащить ничего лишнего. Я предпочитаю передавать GET-параметры в качестве словаря и сериализовать их отдельным методом objectToQuery:
import {CALL_API} from 'redux-api-middleware'; const initGet = (api) => (entity, params) => ({ [CALL_API]: { endpoint: `${api[entity].endpoint}${objectToQuery(params)}`, method: 'GET', types: api[entity].types } });
Инициализируем сам creator:
const get = initGet(config.api);
Теперь, вызывая с нужными аргументами метод get, мы отправим запрос о необходимых данных. Теперь надо позаботиться о том, как полученные данные хранить — напишем reducer.
Reducer
Точнее, два. Один будет класть в store сущности, а другой — время их прихода. Хранить их в одном месте — плохая идея, ведь тогда мы будем смешивать чистые данные с локальным состоянием приложения на клиенте (ведь время прихода данных у каждого клиента свое).
Тут нам понадобятся те же successActionTypes и react-addons-update, который обеспечит иммутабельность store. Тут нам надо будет пройтись по каждой сущности из entities и сделать отдельный $merge, то есть, совместить ключи из defaultStore и receivedData.
const entitiesReducer = (entities = defaultStore, action) => { if (action.type in successActionTypes) { const processedData = {}; const receivedData = action.payload.entities || {}; for (let entity in receivedData) { processedData[entity] = { $merge: receivedData[entity] }; } return update(entities, processedData); } else { return entities; } };
Аналогично для timestampReducer, но там мы будем устанавливать текущее время прибытия данных в store:
const now = Date.now(); for (let id in receivedData[entity]) { entityData[id] = now; } processedData[entity] = { $merge: entityData };
schema или lifetime, successActionTypes понадобятся нам при инициализации — аналогичный код мы писали в action creator'е.
Чтоб получить defaultState, сделаем так:
const defaultStore = {}; for (let key in schema) { // или lifetime, для второго reducer'а defaultStore[key] = {}; }
successActionTypes можно получить из конфига api:
const getSuccessActionTypes = (api) => { let actionTypes = {}; for (let key in api) { actionTypes[api[key].types[1]] = key; } return actionTypes; };
Это, конечно, задача простая, но один такой простой reducer сэкономит нам кучу времени на написании своего reducer'а для каждого типа данных.
Рутинная работа закончена — перейдем к основному компоненту нашего пакета, который и будет заботиться о том, чтоб ходить только за теми данными, которые реально нужны, и при этом не заставлять нас думать об этом.
Middleware
Напомню, что мы считаем, что к нам приходят сразу нормализованные данные. Тогда в middleware мы должны пройтись по всем данным, полученным в entities, и собрать список id отсутствующих связанных сущностей, и сделать запрос к API за этими данными.
const middleware = store => next => action => { if (action.type in successActionTypes) { // Если это action, в котором пришли данные const entity = successActionTypes[action.type]; // Определяем тип данных const receivedEntities = action.payload.entities || {};; // Достаем пришедшие сущности const absentEntities = resolve(entity, store.getState(), receivedEntities); // Находим отсутствующие for (let key in absentEntities) { const ids = absentEntities[key]; // Получаем список id отсутствующих if (ids instanceof Array && ids.length > 0) { // Если список не пустой store.dispatch(get(key, {id: ids})); // Отправляем action, который идет за этими и только этими данными } } } return next(action); }
successActionTypes, resolve и get нужно передавать middleware при инициализации.
Осталось только реализовать метод resolve, который будет определять, каких данных не хватает. Это, пожалуй, самая интересная и важная часть.
Для простоты мы будем считать, что в store.entities хранятся наши данные. Можно и это вынести как отдельный пункт конфига, и присоединять туда reducer, но на данном этапе это неважно.
Мы должны вернуть abcentEntities �� словарь такого вида:
const absentEntities = {users: [1, 2, 3], posts: [107, 6, 54]};
Где в списках хранятся id отсутствующих данных. Чтоб определить, каких данные отсутствуют, нам и пригодятся наши schema и lifetime из конфига.
Вообще, по foreign key может лежать и список id, а не один id — никто не отменял many-to-many и one-to-many relations. Это нам надо будет учесть, проверив тип данных по foreign key, и, если что, сходить за всеми из списка.
const resolve = (type, state, receivedEntities) => { let absentEntities = {}; for (let key in schema[type]) { // проходим по всем foreign key полученных const keyType = schema[typeName][key]; // Получаем тип foreign key absentEntities[keyType] = []; // Инициализируем будущий список отсутствующих for (let id in receivedEntities[type]) { // Проходим по всем полученным сущностям // Проверка на список let keyIdList = receivedEntities[type][id][key]; if (!(keyIdList instanceof Array)) { keyIdList = [keyIdList]; } for (let keyId of keyIdList) { // Проверяем, есть ли id в store const present = state.entities.hasOwnProperty(keyType) && state.entities[keyType].hasOwnProperty(keyId); // Проверяем, есть ли он в receivedEntities const received = receivedEntities.hasOwnProperty(keyType) && receivedEntities[keyType].hasOwnProperty(keyId); // Проверяем, не просрочены ли данные? const relevant = present && !!lifetime ? state.timestamp[keyType][keyId] + lifetime[keyType] > Date.now() : true; // Если он получен в данном action, или лежит в store и актуален, класть его в absent нет смысла if (!(received || (present && relevant))) { absentEntities[keyType].push(keyId); } } } };
Вот и все — немного головоломной логики и рассмотрения всех случаев, и наша функция готова. При инициализации надо не забыть передать в нее schema и lifetime из конфига.
Заключение
В целом, все уже работает, если мы примем такие допущения:
- Можно обойтись без тестирования.
- Никто и никогда не допустит ошибку в конфигах.
- Данные приходят в middleware уже нормализованными.
Все эти пункты (особенно первый!) необходимо тщательно проработать, и мы это сделаем в третьей части. Но это уже не так интересно, ведь почти весь код, выполняющий нашу цель, уже написан, поэтому для тех, кто захочет просто посмотреть и потестить самостоятельно, привожу ссылки:
