GeoDB Cities GraphQL

फ्रीमियम
Verified
GraphQL
द्वारा Michael Mogley | अपडेट किया गया 4 days ago | Data
लोकप्रियता

9.1 / 10

लेटेंसी

41ms

सेवा का स्तर

100%

Health Check

N/A

सभी चर्चाओं पर वापस जाएं

is anything non-nullable?

asking because currently, no fields are non-nullable, which makes it quite frustrating to work with in typescript since you need unsafe type assertions, or a bunch of manipulation (?? null) that may not be necessary at all.

i’m asking because maybe the author is not aware/forgot about non-nullable types?
… well i guess not, since there are non-nullable types in certain queries.

so the question should instead be, is it intentional that most fields are nullable?
just wondering since it’d be a lot easier if, say, PopulatedPlaces were guaranteed to have, say, name, latitude and longitude at the very least

Rapid account: Wirefreethought
wirefreethought Commented 2 years ago

I see. Well you can simply assume that GeoDB will never stuff a null element into a collection.

Rapid account: Ehernlee Rql Gc W 6 Mke K
ehernlee-rqlGcW6MkeK Commented 2 years ago

oops, i haven’t checked here for a while - but i do believe that type would mean the array won’t contain nulls?
(i don’t think there’s a type for “non-empty array” in graphql)

re: [Foo!] see this
… well actually see the official docs (search [Episode!]!)

Rapid account: Wirefreethought
wirefreethought Commented 2 years ago

No, because it should always be possible (though admitedly not desirable) to get an empty list of places.

Rapid account: Ehernlee Rql Gc W 6 Mke K
ehernlee-rqlGcW6MkeK Commented 2 years ago

looks great, thanks!

one small question though - should the type for edges perhaps be e.g.: [PopulatedPlaceEdge!]! rather than [PopulatedPlaceEdge]!?

Rapid account: Wirefreethought
wirefreethought Commented 2 years ago

Schema has been refreshed. Check it out.

Rapid account: Wirefreethought
wirefreethought Commented 2 years ago

Hi again. Depending on how you structure the query, yes some result fields will necessarily be non-null (e.g., if you set a minPopulation constraint, you can expect population to be there - although I think population may actually be guaranteed to be defined at this point). You make a fair point about the schema. I think it’s reasonable to have it reflect what result fields are guaranteed non-null. I will update it accordingly. Stay tuned.

Rapid account: Ehernlee Rql Gc W 6 Mke K
ehernlee-rqlGcW6MkeK Commented 2 years ago

oh there’s no issue with normalizing since that’s what i have to do anyway, i just think it’d be nice to make things less complicated unless they’re strictly necessary.
so yeah, i think it’d be great if that was reflected in the schema.

for context (not that it matters), i’m using apollo’s typescript type generation - the idea being, if the types are generated that’s less room for error

anyway… then my question now is, if certain arguments are used in the query, the corresponding fields on the results are also guaranteed to be non-null right? (i’m assuming yes but it doesn’t hurt to make sure)
i’m pretty sure graphQL isn’t capable of specifying that in the type system itself, but it’d be nice to have some confirmation (ideally in the docs) if that is indeed the case (and a note if it isn’t the case)

Rapid account: Wirefreethought
wirefreethought Commented 2 years ago

Thanks for your question. There are relatively few fields that in practice are non-nullable. They would be id/code/name/population. The rest are not guaranteed. Do you need this specifically reflected in the schema? Also with regards to typescript, what is the issue with having a client layer that normalizes the response by checking for nulls and providing default values as appropriate?

चर्चा में शामिल हों - नीचे टिप्पणी जोड़ें:

नई टिप्पणियाँ पोस्ट करने के लिए लॉग इन / साइनअप करें