Нужно ли создавать локальный уровень данных / состояние приложения, чтобы поддерживать его в приложении React Native / Firestore? - PullRequest
2 голосов
/ 16 апреля 2020

Главное преимущество Firestore - это возможность использовать его как источник правды онлайн / офлайн. Я использую его таким образом прямо сейчас: обновляю документ Firestore непосредственно в действии, затем слушаю изменения базы данных Firestore и отображаю это обратно в локальное состояние. Однако полагаться на эту компенсацию задержки и отображение обратно в локальное состояние недостаточно для быстрых обновлений (касания, переключения даже при небольшом размере документа). Например, переключатели будут «дрожать», когда переключатель RN предположительно переключается при нажатии, а локальное состояние не обновляется до тех пор, пока оно уже не вернет , см. Пример видео . На Android оно выглядит хуже, и проблема не ограничивается только переключениями basi c.

  1. Будет ли какая-либо из следующих компенсаций задержки воздействовать?

    • Размер документа (наши документы сейчас очень малы, и мы предполагаем, что увеличение их размера повлияет на компенсацию задержки).
    • Размер набора результатов запроса. Наш набор результатов - худший случай 1000 документов. Будет ли меньший размер результата запроса влиять на задержку компенсации?
    • Использование запросов с пользовательскими индексами. Примечание: в настоящее время мы не читаем из кэша, мы используем JS SDK
    • Несколько записей. Не ухудшит ли множественные записи один и тот же документ (4 быстрых записи против 2 быстрых записей)
    • Использование встроенного модуля против JS. В настоящее время мы используем Firestore Web SDK с приложением Expo. Мы бы предпочли не извлекать из Expo на данный момент, но посмотрим, улучшится ли компенсация задержки.
  2. Распространено ли для людей создание локального слоя подкладки данных / состояния локального приложения с приложениями React Native / Firestore? Существуют ли какие-либо предлагаемые библиотеки для этого?

При загрузке приложения подключите прослушиватель и экспортируйте результат в контекст для использования через приложение

const [user, setUser] = useState();

firebase.firestore().collection(`users/${user.uid}`).onSnapshot(qs => setUser(oldState => {
    const newState = {};
    qs.docChanges().forEach(change => {
      if (change.type === "added" || change.type === "modified") {
        newState[change.doc.id] = {
          docid: change.doc.id,
          ...change.doc.data(),
        };
      } else if (change.type === "removed") {
        delete oldState[change.doc.id];
      }
    });

    return {
      ...oldState,
      ...newState,
    };
  }))

Пример компонента и функции для переключения уведомлений: (переключение дрожит)

const toggleNotifications = (user, value) => {
  firebase.firestore().doc(`users/${user.uid}`).update({
    wantNotifications: value,
  });
};

const TestComponent = () => {
  //gets from context, set in listener mounted on app load
  const { user } = useUserContext();
  return (
    <Switch
      value={user.wantNotifications}
      onValueChange={value => toggleNotifications(user, value)}
    />
  );
};

1 Ответ

0 голосов
/ 17 апреля 2020

Это не ответ, просто длинный комментарий:)

@ learning Angular Например, в toggleNotifications просто нужно вызвать asyn c создателя действия и не беспокойтесь о размещении логики c внутри реагирующего компонента.

Вместо этого шаблон Redux дает пространство для выполнения некоторой логики, в данном случае потому, что решение пользователя в последний момент является источником правды, поэтому функция диспетчеризации всегда устанавливает локальные tempState и updatingStatus до начала обновления firestore, затем после Обязательство Firestore либо решено, либо отклонено отправляет действие редуктору для сброса updatingStatus. Тогда селектор проверит, является ли updatingStatus истинным, просто полагаться на локальный tempState, в противном случае полагаться на прослушиваемое состояние пожарного хранилища. Наконец, отреагируйте на результат выбора использования компонента как текущее действительное состояние.

Я не отвечаю на этот вопрос, потому что у меня нет такого большого опыта. Мне также любопытно, есть ли хорошее решение, но это то, что я считаю решением на данный момент.

...