Feedback: implementation of key helpers like `geoDistance()`and `via()`

[sergio9929]

PocketBase v0.27.0 has introduced a new field type GeoPoint, along with a new function geoDistance(), which can be used in API rules and queries.

Here are our proposals for implementing this new function:

const point = {
  lon: 10,
  lat: 12,
}

pbQuery<User>()
  .greaterThan('location', distanceFrom(point, 25)) // 25km
  .build(pb.filter)
  // geoDistance(location.lon, location.lat, 10, 12)>25

pbQuery<User>()
  .greaterThan(geoDistance('location', point), 25) // 25km
  .build(pb.filter)
  // geoDistance(location.lon, location.lat, 10, 12)>25

To align with PocketBase's querying syntax, we prefer the second option:

pbQuery<User>()
  .greaterThan(geoDistance('location', point), 25) // 25km
  .build(pb.filter)
  // geoDistance(location.lon, location.lat, 10, 12)>25

[sergio9929]

I'm not being able to infer the correct field names when using geoDistance() like this:

pbQuery<User>()
  .greaterThan(geoDistance('location', point), 25) // 25km
  .build(pb.filter)
  // geoDistance(location.lon, location.lat, 10, 12)>25

So I thought I'd try a slightly different approach:

pbQuery<User>()
  .greaterThan(k => k.geoDistance('location', point), 25) // 25km
  .build(pb.filter)
  // geoDistance(location.lon, location.lat, 10, 12)>25

[sergio9929]

This is close to being finished, I just want to narrow the allowed keys in geoDistance.

[sergio9929]

KeyHelpers

via (Back-relations)

Introduction - Working with relations - Docs - PocketBase

pbQuery<Post>().anyLike(
    (k) => k.via('comments', 'postId', 'author.name'),
    'Sergio',
)
// comments_via_postId.author.name ?~ 'Sergio'

geoDistance

Introduction - API rules and filters - Docs - PocketBase

pbQuery<Post>().lessThan((k) => k.geoDistance('pointA', { lon: 5, lat: 6 }), 5)
// geoDistance('pointA.lon', 'pointA.lat', 5, 6) < 5

[sergio9929]

I have succesfuly implemented geoDistance(), but I'm having a really hard time implementing via().

These are the options I have considered:

// One
pbQuery<Post, CollectionMap>().anyLike(
    (k) => k.via('collection1', 'field'),
    'value',
)

// One
pbQuery<Post, CollectionMap>().anyLike(
    (k) => k.via('collection1.postId', 'field'),
    'value',
)

// One
pbQuery<Post>().anyLike(
    (k) => k.via<Collection1>('collection1', 'postId', 'field'),
    'value',
)

// One
pbQuery<Post, CollectionMap>().anyLike(
    (k) => k.via('collection1', 'postId', 'field'),
    'value',
)

// Multiple
pbQuery<Post, CollectionMap>().anyLike(
    (k) =>
        k
            .via('collection1', 'postId', 'field')
            .via('collection2', 'postId', 'field'),
    'value',
)

// Multiple
pbQuery<Post, CollectionMap>().anyLike(
    (k) =>
        k.via('collection1', 'postId', 'field', (k) =>
            k.via('collection2', 'postId', 'field'),
        ),
    'value',
)

// Multiple
pbQuery<Post, CollectionMap>().anyLike(
    (k) =>
        k.via(
            ['collection1', 'postId', 'field'],
            ['collection2', 'postId', 'field'],
        ),
    'value',
)

However, none of these options fully meet the following requirements:

• Autocompletion and accurate IDE suggestions.
• Type inference for collection, recordId and field.
• Type inference for value.

[sergio9929]

I'm not being able to infer the correct field names when using geoDistance() like this:

pbQuery()
.greaterThan(geoDistance('location', point), 25) // 25km
.build(pb.filter)
// geoDistance(location.lon, location.lat, 10, 12)>25
So I thought I'd try a slightly different approach:

pbQuery()
.greaterThan(k => k.geoDistance('location', point), 25) // 25km
.build(pb.filter)
// geoDistance(location.lon, location.lat, 10, 12)>25

Good news! Thanks to @david-plugge/typed-pocketbase and this code block* I managed to infer the correct field names when using geoDistance() like this:

pbQuery<User>()
  .greaterThan(geoDistance('location', point), 25) // 25km
  .build(pb.filter)
  // geoDistance(location.lon, location.lat, 10, 12)>25

But, despite being more verbose, I think I prefer the other syntax because the IDE can suggest all available key helpers.

*The technique used in the code block is called nominal typing.