Token byDocument seems to not work as expected

[fhijlkema]

Whenever I try to select a token that is created on a document by using the built in byDocument method, it returns an error.

Token.byDocument(roles.byId("387163802190217805"))
Returns the following error:

error: Type `Null` is not a subtype of `{ *: Any }`

If I instead use firstWhere to select the very same document’s token, it works as expected.

Token.firstWhere(.document == roles.byId("387163802190217805"))

Is this a bug, or do I need to formulate this query otherwise?

[ptpaterson]

You need to assert that the document is not null. You can do that using the “null assertion operator” ! FQL: Operators - Fauna Documentation

Token.byDocument(roles.byId("387163802190217805")!)

Why?

The signature of Token.byDocument is

Token.byDocument(document: Document): Token | TokenNull

see: FQL API: Token.byDocument() - Fauna Documentation

But the signature of <Collection>.byId is

byId(id: id | Int ): <Document> | Null<Document>

see: FQL API: byId() - Fauna Documentation

[fhijlkema]

Thanks for clarifying!

[sumerokr]

Could you help me to better understand it and build a better mental model?

TypeScript (and FQL is inspired by TS, right?) gives us type hints/warnings in IDE and doesn’t affect the runtime. E. g. if you use something that has a type User | null, and try to access its property, like user.name TS shouts at you, because a user could be null, therefore it is dangerous and could fail at runtine. If you know it is definitely a User, you can use user.name! to calm TS down. And it has no impact on runtime stability.

In short (TS):

• gives you type hints/warnings in IDE
• does not affect your runtime (regardless of !)

From what I understand from above messages, FQL works differently.
It doesn’t give you a hint/warning in shell about type missmatch for the given code Token.byDocument(roles.byId("387163802190217805")).
Instead, type missmatch has an impact at your runtime and could cause a fail, even if the value itself is good (not null).

In short (FQL):

• doesn’t give you type hints/warnings in shell
• does affect your runtime

Am I correct with these statements?

Thanks in advance!

[ptpaterson]

Hi @sumerokr The errors are in FQL and TS are similar, though TS errors are clearly more refined.

Here is the type hint in the Fauna web shell

Here’s a contrived equivalent in TS

The FQL type { *: Any } is equivalent to TS type { [key: string]: any }.

We can see that the second line in the TS error is quite similar to the FQL error.

// FQL
Type `Null` is not a subtype of `{ *: Any }`

// TS
Type 'null' is not assignable to type '{ [key: string]: any; }'

The difference is TS wraps the error in some additional context. Improving error messages, type hints, etc. is something we are continuing to work on.

[ptpaterson]

@sumerokr

does not affect your runtime (regardless of !)

And to address this directly: Typechecking is now on by default, but you can turn it off. When type checking is on you get a type error before the query runs. This is no different than you having to compile typescript prior to running it as javascript. If you turn off typechecking, it’s just like crossing your fingers and hoping you don’t get runtime errors in javascript.

[sumerokr]

Thanks for your answer! I was confused by the screenshot from the original topicstarter’s message.
You can see there is no type warning there. But now I realize it’s probably because the request has already been executed.

So FQL does type cheking in shell. And you have just proved it with the first screenshot from the message above, thanks!
And the error faced by the topicstarter is not a runtime fail, but more like a TypeScript compile-time warning. Good to know!

Friendly hint: you don’t have to implement logic in TS to make a scowcase. There is a useful declare thing.