https://typesense.org logo
Join Slack
Powered by
Is <this issue> meant as an "evergreen" issue for ...
# contributions
a
Is this issue meant as an "evergreen" issue for all Typescript related issues for typesense-js?
j
Not really... Hoping to address any glaringly missing issues with the first Typescript release in that thread
Once we do one more release with a round of fixes, I was thinking we can then close that issue and ask for a new GH issue to be created going forward for each new issue
a
Yeah, makes sense
j
Sounds good! Thanks Akash!
a
Can you list down any glaring issues in the thread as well?
j
So far that geo search response is the only one... We've addressed all other known issues with the TS conversion
✅ 1
Btw, I added a few more issues last week to Github (unrelated to Typescript): https://github.com/typesense/typesense-js/issues
a
I'll try to infer its type from the server codebase. Don't see any hits for 
geo_distance_meters
on typesense-js
j
Yeah that comes from the server...
It's an integer
a
In the docs I see
Copy code
"geo_distance_meters": {"location": 1020}
So I'm guessing it's an interface with a set of keys
j
Oh right yes
"location" is the name of the geopoint field that users indicate in the Collection's schema
a
I see. So it's user definable?
j
Yeah
a
I see. Then we can accept a type for it from the user itself
j
Just the keys within that object
Are we able to re-use the DocumentSchema, which is a type users define elsewhere already?
a
I think that's doable, if the user passes in a specific key on which the type for that exists. So the above interface would have another property 
geo_distance_meters: T["geo_distance_meters"]
(in case we decide to name the special key 
geo_distance_meters
)
j
So users already specify all the keys in their documents in DocumentSchema. Can we define the type to say something like, 
geo_distance_meters: Object can contain any of the keys from DocumentSchema, with integers for a value
(pseudo code)
a
Yup, we can
Record<keyof T, number>
This makes the typing unstable/unreliable though, since not all keys of T are valid keys in 
geo_distance_meters
, which is where a specific key on 
T
for defining this type would help.
j
There can be multiple geopoint fields though
Ideally, this is the most precise definition:
geo_distance_meters: Object can contain keys from DocumentSchema which themselves have a type of "geopoint", with integers for a value
✅ 1
a
Yeah, I mean 
T
would be structured like:
Copy code
interface Document {
  keys of T;
  geo_distance_meters: {
   some_other_keys
  }
}
j
geo_distance_meters
is not a property that exists within the Document though...
Copy code
{
  "facet_counts": [],
  "found": 1,
  "hits": [
    {
      "document": {
        "id": 0,
        "location": [
          48.86093481609114,
          2.33698396872901
        ],
        "points": 1,
        "title": "Louvre Museuem"
      },
      "geo_distance_meters": {
        "location": 1020
      },
      "highlights": [],
      "text_match": 16737280
    }
  ],
  "out_of": 1,
  "page": 1,
  "request_params": {
    "collection_name": "places",
    "per_page": 10,
    "q": "*"
  },
  "search_time_ms": 0
}
So document is a standalone object, inside the search result hit array of objects
and 
geo_distance_meters
is a key of search result hit
a
This explains it, thanks.
👍 1
Open in Slack
PreviousNext
Powered by