state.firestore.status.requesting has elements set to true, even after data is present in state.firestore.data

What is the current behavior? Some times, like 1% or 2% of the times I load a screen in my React Native app, one of the documents that are connected with firestoreConnect to that screen, still has true as requesting status.

I currently show a spinner on top of the UI if any document is true in the requesting object. And false in the requesting object.

This issue is very hard to reproduce, especially when the React Native Debugger is enabled. But I managed once to inspect the redux store, and I can see that the path which is still requesting, has got its data in state.firestore.data, and the UI has all its content, below the spinner I show.

I can see the LISTENER_RESPONSE action for the path that was listed as requesting, in the action history, and as said, the content is present at the storeAs key in the action.

I apologize for the vague description and debugging, and missing reproduction steps, but it’s only happening about 1% of the times I load a screen, so it’s really hard to debug.

What is the expected behavior? I expect state.firestore.status.requesting to correctly reflect the current status, so I can use it for indicating whether data is currently being loaded

Which version of redux-firestore are you using? What about other dependencies?

    "react-native-firebase": "^5.3.1",
    "react-redux": "^5.1.1",
    "react-redux-firebase": "^2.2.6",
    "redux": "^4.0.1",
    "redux-devtools-extension": "^2.13.8",
    "redux-firestore": "^0.7.2",
    "redux-persist": "^5.10.0",
    "redux-thunk": "^2.3.0"

Also tested with newest versions redux-firestore@0.8.0 and react-native-firebase@2.4.0, still having the issue 😦

Which environments/browsers are affected by this issue? Did this work in previous versions or setups? React native 0.59.10 both Android 5-9 and iOS 12

Here is a snapshot of my firestore branch of the state:

  firestore: {
    status: {
      requesting: {
        'users/iAWZXwc2MoaYjPD5FJIunwmipgC2/attributes/favoriteTeams': false,
        followingTeams: false,
        tournaments: false,
        'seasons/sr:season:67253/attributes/teams': true,        // THIS IS WRONG
        'localizations/teams/languages/en': false,
        'seasons/sr:season:66441/attributes/teams': false
      },
      requested: {
        'users/iAWZXwc2MoaYjPD5FJIunwmipgC2/attributes/favoriteTeams': true,
        followingTeams: true,
        tournaments: true,
        'seasons/sr:season:67253/attributes/teams': false,    // THIS IS WRONG
        'localizations/teams/languages/en': true,
        'seasons/sr:season:66441/attributes/teams': true
      },
      timestamps: {
        'users/iAWZXwc2MoaYjPD5FJIunwmipgC2/attributes/favoriteTeams': 1565987383715,
        followingTeams: 1565987383727,
        tournaments: 1565987385813,
        'seasons/sr:season:67253/attributes/teams': 1565987385814,
        'localizations/teams/languages/en': 1565987385815,
        'seasons/sr:season:66441/attributes/teams': 1565987385847
      }
    },
    data: {
      tournaments: {
.........
        }
      },
      'localizations/teams/languages/en': {
        expiration: '2020-01-30',
        body: {
........
        }
      },
      'seasons/sr:season:66441/attributes/teams': {
        expiration: null,
        body: {
..............
        }
      }
    },

[esbenvb]

Thanks! I’ll do that for the future. I was no aware of the pattern where I could have first a connect block mapping state to props, then firestoreConnect block reading the props and then another connect block mapping the firestore state to props

[prescottprue]

@esbenvb good to know, thanks. Saw your PR.

Something to keep in mind is that you should avoid using store.getState within your queries since it is known to cause some issues where state changes and does not correctly re-render since there wasn’t a props change. It is better to connect to state and pass the values as props:

export default compose(
  connect(
   (state) => ({ activeTournament: state.general.activeTournament }),
    mapDispatchToProps
  ),
  firestoreConnect((props: Props) => {
    if (!props.activeTournament) {
      return [fq.allTournaments.query()]
    }
    return [
      fq.allTournaments.query(),
      fq.seasonTeams.query(activeTournament.currentSeason.id),
      fq.localizedTeams.query(currentLanguageCode),
    ]
  }),
  connect(
   (state) => {
      // data state connection here
   }
  )
)(SignupFollowScreen)

This also helps to prevent unnecessary re-renders of firebaseConnect as data is received. The re-render of firebaseConnect will only happen if the props which are passed to it changed…

As for your @ts-ignore comment - is that still an issue in the types for you? I thought that issue was noted to be coming from the react-native setup and not from bad types for firebaseConnect?