-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[FormRecognizer] Fix an issue accessing undefined object #8748
Conversation
This should wait for #8747 to be merged first. |
when input document to receipt recognition contains blank pages
9cb5687
to
c894276
Compare
/azp run js - formrecognizer - tests |
Azure Pipelines successfully started running 1 pipeline(s). |
Part of #8706 |
also added back confidence for receipt type.
return "itemized"; | ||
} else { | ||
return "unrecognized"; | ||
if (type.valueType === "string") { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I get a little bit spooked out by this block. The type signature suggests that "gas"
and "parking"
are also valid values of type
, and it feels like we're doing too much to transpose FormField
into USReceiptType
here. Is there any reason we couldn't return type.valueType
in all cases where it's defined and then use "unrecognized"
otherwise?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I missed the confidence
field on receipt type, it will be included in another PR so we will be returning `{ confidence: 1, type: "itemized" }
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh it's in this PR
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So the valueType
for a ReceiptType field should be "string" and the value of the field type.value
is the receipt category, which is capitalized and I want to transform it into the camelCase that we normally use in TypeScript.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we are fine with capitalized string literals for receipt types then yes we can return them directly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hmm returning type.value
which has a string
type as stronger receipt type might not be valid here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like TypeScript compiler can correctly narrow down the to the valid string literals. I refactored this to use a switch statement. Hopefully it reads better.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cool, I like the tweak with the switch statement.
/azp run js - formrecognizer - ci |
Azure Pipelines successfully started running 1 pipeline(s). |
/azp run js - formrecognizer - tests |
Azure Pipelines successfully started running 1 pipeline(s). |
when input document to receipt recognition contains blank pages