feat(query): clearing data after unset listener

[apietrzak]

Do you want to request a feature or report a bug?
bug

What is the current behavior?
If i want to change a document listener to another id, then previous data is still existing until new data is received.

What is the expected behavior?
After removing the listener, the data connected to that listener should be removed.

Which versions of dependencies, and which browser are affected by this issue? Did this work in previous versions or setups?
Newest

Steps to reproduce and if possible a minimal demo of the problem via codesandbox or similar.

[
    {
        collection: 'collections',
        doc: props.collectionId,  // data from my reducer. If this id is changed then previous data is still existing
        storeAs: 'collection'
    }
]

[prescottprue]

This is the intention because you are using a non unique storeAs for a document listener. Each listener has different settings (i.e. different doc id), but have the same storeAs, which means they will run over each other. Try making a dynamic storeAs:

[
    {
        collection: 'collections',
        doc: props.collectionId,  // data from my reducer. If this id is changed then previous data is still existing
        storeAs: `collection/${props.collectionId}`
    }
]

Make sure that you get the values out of state from the new location.

This pattern is actually what is followed by default for sub-collections in the v1.0.0-* pre-release versions available when installing from the alpha tag. There is also new state selection utilities so that you can use the same config for listeners/state connection.

All of that said, not sure I am seeing the case for storeAs with your current listener, so maybe just removing that is even easier for now?

[apietrzak]

@prescottprue
I understand it, but still, i don't need that data in the store if a listener was removed. For example: A user iterates over 100 collections, then it's taking 100 entries in the store.

Listener config:
[
    {
        collection: 'collections',
        doc: props.collectionId,
    }
]

State:
collections: {
    collectionID1: {...}
}

Actions:
UNSET_LISTENER
SET_LISTENER
LISTENER_RESPONSE

New state:
collections: {
   collectionID1: {...},   // I don't need that
   collectionID2: {...}
}

Additionaly, when the user backs to the first collection then in the store is still old data and will be refreshed soon, which means the user will see old view of my appliaction instead of loading screen. In my case, there will be better to remove that data and load it one more time if needed. For example by adding argument to listener config:

[
   {
        collection: 'collections',
        doc: props.collectionId,
        removeOnUnset: true
   }
]

[prescottprue]

@apietrzak While I don't dislike the idea, I am not sure I fully understand the use case. Since the data has already been queried, there is no real reason to not have it right?

I believe I understand what you are describing - If you use the storeAs method mentioned above, then you are effectively "clearing" the data whenever it is being "unset".

You can also dispatch CLEAR_DATA action type to remove data from state, but honestly storeAs feels like a good way to go.

[eldoner]

@prescottprue Could you explain the difference between reducers ordered and data?
And How can I use a populate with example you provided:

[
    {
        collection: 'collections',
        doc: props.collectionId,  // data from my reducer. If this id is changed then previous data is still existing
        storeAs: `collection/${props.collectionId}`
    }
]

Thanks!

[prescottprue]

@eldoner your question doesn't really seem to relate to the issue, so if you want more info you may have to open another issue or reach out over gitter. That said, the queries section of the docs explains the difference between the two pieces of state. Population is done with data since things are by key.

[eldoner]

@prescottprue Actually it is related. I know that state.firebase.ordered is array fromatted and state.firebase.data contains data store by key, but as I understand correctly from you anserws above, state.firebase.data contains all data which was 'listened' before.
I have similar problem as author, so I want to use storeAs but I need to populate data, which I don't know how to use in this situation.
Thanks for understanding.

[apietrzak]

@prescottprue
Ok, let's see at this example:
I contains query for selecting data interesting for me:

       {
            collection: 'addons',
            storeAs: 'addons',
            where: ['pageID', '==', firestore.doc(`pages/${props.pageId}`)]
        }

that addons are stored to addons field. But also this query is based on pageId, so when my pageId is changing i don't know when my data is available. So, I can change storeAs to addons/${pageId} but now in the store will be data for all queries and when i will back to previous page then at first I will see the old data (which is in the store) and at next new data is received from db and view is refreshed. And that is my problem. I don't want to store data which is unuseful for me and I dont have easy way to remove that data. Additionaly, when my data is stored as const storeAs key, then i dont know if this data is queried by current query or previous one. For me fixing isLoading will be fine, but now it is not usable, because this function checks if in the store is some data, but doesn't check if that data is listened and received from db at least once after listing on it, and if is downloaded by current query.

[Wgil]

[
    {
        collection: 'collections',
        doc: props.collectionId,
        storeAs: `collection/${props.collectionId}`
    }
]

Doesn't solve my use case. My listeners are set on users actions so, when the user comes back to the page, the collection is still there.

CLEAR_DATA helped me to achieve this but for some reason the state is not being deleted from the data key.

// Delete events from state
      dispatch({
        type: actionTypes.CLEAR_DATA,
        preserve: {
          ordered: ({ collection, ...rest }) => rest,
          data: ({ collection, ...rest }) => rest
        }
      })

@prescottprue Am I missing something? Thank you

[esbenvb]

I agree with @apietrzak - of course we can store the data with a custom-made key for each document, but that will not only make the app a bit code more complex, it also leads to memory leaks, when the user is browsing around in 100s or 1000s of pages in the app, all these are kept in the store, because they were once loaded.

I don't see any solutions that are more elegant than the removeOnUnset: true option suggested.

[varunyn]

Any update on this issue?