While creating PR #184 a concern arose wherein the type applied to the auth0Id value in a few places was a string which also happens to accept null and undefined as valid values.
The suggestion at the time was to manually coalesce falsey values to '' using something like this:
Which this will certainly work, I don't believe it's not an ideal habit for us to establish. More specifically, I don't think it's a good use of time to manually enforce a level of type safety that the type checker itself is allowing.
What I propose instead is one or both of the following options:
- Enable strict null checks so that none of the types in the system allow null/undefined unless told to do so explicitly. More can be read on this [here](Nullable Types: https://www.typescriptlang.org/docs/handbook/advanced-types.html#nullable-types).
- Make a custom type just for the
auth0Id that adds type-safe validation as well. Here's an article covering one potential approach.
I'm not expecting any immediate progress on this topic. I think it's wise for us to consider whether or not we want to solve this problem at all, and, if so, how soon we want to solve this problem.
While creating PR #184 a concern arose wherein the type applied to the
auth0Idvalue in a few places was astringwhich also happens to acceptnullandundefinedas valid values.The suggestion at the time was to manually coalesce falsey values to
''using something like this:Which this will certainly work, I don't believe it's not an ideal habit for us to establish. More specifically, I don't think it's a good use of time to manually enforce a level of type safety that the type checker itself is allowing.
What I propose instead is one or both of the following options:
auth0Idthat adds type-safe validation as well. Here's an article covering one potential approach.I'm not expecting any immediate progress on this topic. I think it's wise for us to consider whether or not we want to solve this problem at all, and, if so, how soon we want to solve this problem.