firebase
Provide a consistent way of accessing the Firestore query on firestore.Query
[REQUIRED] Describe your environment
- Operating System version: MacOS Catalina 10.15.1
- Browser version: Chrome, Firefox, Safari, Edge
- Firebase SDK version: 7.14.2
- Firebase Product: Firestore
[REQUIRED] Describe the problem
We need access to the string representation of the database query stored in firebase.firestore.Query. We're using it to create a key for caching queries.
function getCacheKey(query: firebase.firestore.Query) {
return query.wp.toString(); // returns something like Query(....
}
The problem is that this variable wp has been obfuscated by the build process. If you change the version of the Firebase SDK, this variable name will change.
Can you provide a consistent way of accessing this property? Either through a method or through a instance variable that won't be obfuscated.
Thanks!
Thanks for reporting this. The string representation of a query is an implementation detail that we don't plan to expose (it's not stable and we have changed it previously). One possible workaround is to use an approach similar to ReactFire: store the cache as an array, rely on Query's isEqual method and do a linear search before adding a new entry. Otherwise, you may need to wrap the creation of queries within a function or a class that builds up a stable identifier for the query specific to your app.
Now that the canonicalId doesn't exist, is it possible to have a stable version of https://github.com/firebase/firebase-js-sdk/blob/main/packages/firestore/src/core/query.ts#L438 (canonifyQuery()) exposed? This would be really useful for Server Side rendering as it allows automatically generating keys for each data. Otherwise, we need to force the user to provide a key for queries (while documents and collections do not need this because the path is enough).
Database has a .toString() method to get a representation of the query. A similar version for Firestore would be useful
it's not stable and we have changed it previously
I hope this can be reconsidered… IMO it should be fine to expose if it’s documented that consumers should treat the returned string as opaque data (consumers should not attempt to parse it) and only use it in the following supported use cases:
- As a key for a map or a cache for later retrieval
- As a key for passing server-requested data to client for rehydration, given that both the server and client are running the same version of the library.
When these are the case, the string representation doesn’t have to be stable across versions.
