chore(site): fix typegen usage #868
Conversation
Codecov Report
@@ Coverage Diff @@
## main #868 +/- ##
==========================================
+ Coverage 63.90% 66.05% +2.15%
==========================================
Files 199 203 +4
Lines 11830 13226 +1396
Branches 87 86 -1
==========================================
+ Hits 7560 8737 +1177
- Misses 3442 3603 +161
- Partials 828 886 +58
Continue to review full report at Codecov.
|
| @@ -3,7 +3,7 @@ import * as Types from "../../api/types" | |||
| import * as API from "../../api" | |||
|
|
|||
| export interface UserContext { | |||
| getUserError?: Error | unknown // unknown is a concession while I work out typing issues | |||
| getUserError?: Error | unknown | |||
There was a problem hiding this comment.
Open Question: Maybe this is something we talk about at FE V or down the line; I am documenting it just for completion. I'm wondering if we will strategize around discerning errors using predicates:
const isUserError = (e: any): e is UserError => {
// ...
}If so, we might want to associate errors with types in some meaningful way and logically group these predicates. I'll want to think on that architecturally speaking with you, and I do not feel compelled to make a quick decision yet, as we're OK right now.
as Error, type checking as they come in, or be defensive throughout?)event.typewasSIGN_INeven though the typegen file knew that it was alwaysSIGN_INis that I had annotatedeventasUserEvent. The lesson is, let typegen figure out your types for you.I updated the Code Conventions doc with info on how to use typegen.