Updating query criteria on 3.x

[len-art]

GeoFirestore 2.x had (as does GeoQuery) a feature where you could update the query criteria, mainly the center (and radius) of the query. This was a great way to slightly adjust the query criteria and only getting the changes (which documents are no longer a part of the query and which documents just entered the query range). For example (this is a part of the old API):

const geoQuery = geoFirestore.query({
  center: new firebase.firestore.GeoPoint(10, 2),
  radius: 10.5,
});
geoQuery.updateCriteria({
  center: new firebase.firestore.GeoPoint(11, 3),
});

With 3.x, the only way to adjust the query is to create a new query which fetches all the data again. If the two queries are overlapping, this is a lot of unnecessarily duplicated data being transferred from the backend.

const geoFireStore = new GeoFirestore(firestore)
const listener = geoFireStore.collection('myCollection')
            .near({ center, radius })
            .onSnapshot(...)
...
// unsubscribe from current query
listener()
// create a new listener
const newListener = ...

Is there a way to have an option to just update the query in the 3.x and if not - would it be possible to add it?

Really love your work and how quick you respond to questions.

[MichaelSolati]

@Len-art it would be possible, however it's not a top priority. Because we now keep track of previous and current index I would need to plan how to address the change of a completely new query. So yes it's on my plate, but I haven't gotten on that yet.

[len-art]

Okay, thanks for the response! I thought it could be done similarly to the previous implementation, with just adding a method on the snapshot listener or something similar. My bad :)

[MichaelSolati]

@Len-art so I'm not sure if there's a good way to implement this feature into the library. I know how to do it technically, but am not sure the right way to make it available to users... I'm thinking about possibly making a second library that provides tools and hacks for GeoFirestore and to include a wrapper class for this... Do you have any thoughts?

[MvRemmerden]

@MichaelSolati I was migrating from 2.4.0 to 3.0.0 for security reasons (json-bigint, kind-of and sock-js) and got stuck on this problem.

I was able to circumvent this problem by checking inside onSnapshot() whether we have enough results. If not, I would cancel the request and start a new one with a larger radius, but that could lead to quite a few requests every time getting the same results again and thus eating up a lot of firestore requests. Did I also use these requests so far with updateCriteria(), or was that system somehow smart enough to filter these out?

Either way, would there be any chance for a 2.5.0 version just to update the dependencies, then I could take some more time migrating over to 4 directly 🙂

[MichaelSolati]

@MvRemmerden I haven't looked at 2.x.x in so long I don't know/thing 3+ is smartly handling that for you. Anyway, I don't plan on releasing an update but you could always fork and update the dependencies and install straight from GitHub. Unfortunately my schedule has made it hard to maintain this library and I'm currently working on fixing a bunch of issues that have been opened over the course of the past few months.

Anyway, uhm, yea, fork it, clone it then....

git checkout 05c878381ccc986afa2ba973beeec9f498bf1c88
git checkout -B dependencies

Update the dependencies that you need updated.

git add .
git commit -m "chore: update dependencies"
git push --set-upstream origin dependencies

Jump back into your project

npm uninstall geofirestore
npm install mvremmerden/geofirestore-js#dependencies

Hopefully that'll help you for now.

[MvRemmerden]

[...] you could always fork and update the dependencies and install straight from GitHub

Oh, that's a great idea, thanks so much for pointing this out and adding the instructions!