Какой лучший способ использовать автономный Firestore с Redux? - PullRequest
Новая
       36

Какой лучший способ использовать автономный Firestore с Redux?

0 голосов
/ 04 октября 2018

tl; dr Является ли хорошей практикой обновление хранилища резервов перед тем, как пытаться обновить внутреннюю базу данных (например, Firestore), или существует другое решение "передовой практики"?

В настоящее время у меня есть приложение, созданное с помощью приложения create response.Внутренние данные хранятся в Firestore.Когда приложение первоначально загружается, оно извлекает массив проектов из Firestore и загружает их в хранилище Redux, которое пользовательский интерфейс использует для визуализации контента.

Все хорошо.

Мой вопросо том, как реализовать действия CRUD в автономном режиме (например, создание проекта).Кстати, CRA кэширует приложение, поэтому пользовательский интерфейс работает в автономном режиме (если в хранилище есть данные), поэтому мой вопрос не об этом, а о порядке, в котором лучше всего отправлять данные в Firebase и отправлять (ту же) полезную нагрузкув магазин редуксов.

Обратите внимание, что "db" в приведенной ниже представляет собой подключенную к Firestore базу данных (настроенную в другом месте), и когда я говорю об использовании Firestore в автономном режиме, я говорю о enablePersistence, которое по умолчанию используется в iOS и Android.И я использую Thunk.

Например, я вижу общий шаблон создателя действий Redux, который выглядит следующим образом.В этом случае я использую его для создания нового проекта: 

export const createProject = projectData => async dispatch => {
  dispatch({ type: CREATE_PROJECT_START });
  try {
    await db
      .collection("projects")
      .doc(projectData.project_uid)
      .set({ ...projectData });
    dispatch({ type: CREATE_PROJECT_SUCCESS, payload: projectData });
  } catch (e) {
    dispatch({ type: CREATE_PROJECT_FAIL, payload: e.message });
  }
};

Поведение таково, что отправка полезной нагрузки в Redux не происходит до тех пор, пока обещание не вернется из Firebase.

При тестировании я могу отключить сеть и создать новый проект.Когда вызывается функция createProject (посредством отправки формы), консоль загорается сообщениями net :: ERR_INTERNET_DISCONNECTED, что является ожидаемым поведением.

Однако, когда пользователь возвращается из формы на страницу, которая отображаетво всех проектах новый проект не отображается, потому что обещание Firebase еще не выполнено.

Удивительно, однако, когда я снова включаю сеть (я проверил это всего несколько минут, и яне уверен, насколько хорошо это будет работать после длительного периода времени), Firebase поймает тот факт, что он в сети, отправит данные, вернет обещание, и тогда может произойти отправка в Redux.

Покаудивительно, это не лучший пользовательский опыт, поэтому я реализовал небольшой твик, показанный ниже: 

export const createProject = projectData => async dispatch => {
  dispatch({ type: CREATE_PROJECT_START });
  try {
    dispatch({ type: CREATE_PROJECT_SUCCESS, payload: projectData });
    await db
      .collection("projects")
      .doc(projectData.project_uid)
      .set({ ...projectData });
  } catch (e) {
    dispatch({ type: CREATE_PROJECT_FAIL, payload: e.message });
  }
};

Просто переместив диспетчер Redux до вызова метода set в БДповедение намного лучше, так как проект визуализируется сразу после создания в пользовательском интерфейсе.Фактически пользователь может выполнить несколько изменений, которые правильно отражаются в пользовательском интерфейсе, даже если БД работает в автономном режиме.

Ошибки по-прежнему исчезают в консоли, как и ожидалось.И когда сетевое соединение восстанавливается, Firestore получает данные в фоновом режиме.

Итак, сказав все это, является хорошей / плохой практикой помещать диспетчеризацию в Redux перед обновлением db,и / или есть ли лучший способ сделать это?

...