is anything non-nullable?

Question

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, `PopulatedPlace`s were guaranteed to have, say, `name`, `latitude` and `longitude` at the very least

Michael Mogley · Answer

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

E-Hern Lee · Answer

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](https://stackoverflow.com/questions/46770501/graphql-non-nullable-array-list)
... well actually see the [official docs](https://graphql.org/learn/schema/) (search `[Episode!]!`)

Michael Mogley · Answer

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

E-Hern Lee · Answer

looks great, thanks!

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

Michael Mogley · Answer

Schema has been refreshed. Check it out.

Michael Mogley · Answer

Updated schema docs here: https://wirefreethought.github.io/geodb-cities-graphql-schema-docs

Michael Mogley · Answer

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.

E-Hern Lee · Answer

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)

Michael Mogley · Answer

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?

GeoDB Cities GraphQL

9.3 / 10

53ms

100%

N/A

is anything non-nullable?