GeoDB Cities GraphQL

Por Michael Mogley | Atualizado 5 months ago | Data

9 / 10



Nível de serviço


Voltar para todas as discussões

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

wirefreethought commented 5 months 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?

ehernlee-rqlGcW6MkeK commented 5 months 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)

wirefreethought commented 5 months 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.

wirefreethought commented 5 months ago

Schema has been refreshed. Check it out.

ehernlee-rqlGcW6MkeK commented 5 months ago

looks great, thanks!

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

wirefreethought commented 5 months ago

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

ehernlee-rqlGcW6MkeK commented 5 months 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!]!)

wirefreethought commented 4 months ago

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

Junte-se à discussão - adicione o comentário abaixo:

Efetue login / inscreva-se para postar novos comentários
Avaliação: 5 - Votos: 1