-
Notifications
You must be signed in to change notification settings - Fork 12
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
Require JSON serialization checks "in and out" #179
base: main
Are you sure you want to change the base?
Conversation
index.html
Outdated
<li>If |requests| does not contain [=JSON type=] values, | ||
[=exception/throw=] a {{TypeError}}. | ||
</li> |
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.
This is not right here... you need to:
- [=List/for each=] |request| of |requests|:
1.1. [=serialize a JavaScript value to a JSON string|Serialize=] |request| a to a JSON string. Rethrow any exceptions.
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.
@timcappalli, we also would need this on the way out, when readonly attribute object data;
is set... though there might not be enough spec text in the current spec to add this right now. However, it would be good to add something.
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.
readonly attribute object data
The benefit of also doing this on the way back is that we could make this integrate well with fetch()
... arguably, we could also this in a separate PR ...
This is not right here... you need to:
Yeah, we'd still want to do this, I think.
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.
we also would need this on the way out, when readonly attribute object data; is set... though there might not be enough spec text in the current spec to add this right now. However, it would be good to add something.
@marcoscaceres @samuelgoto isn't this already covered by using the default toJSON()
method?
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.
No. This is because if the wallet returns some bogus value that is not a JSON object (e.g., a string, or a number, will TypeError at this point), then that can't map to .data
(because it's required to be an object). Thus you need to JSON parse the response before it is stored in .data
... then the developer calling .toJSON()
walks both the DigitalCredential instance and the . data
. structure.
Make sense?
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.
Couple of small things...
Co-authored-by: Marcos Cáceres <[email protected]>
@timcappalli, see also #179 (comment) |
Co-authored-by: Marcos Cáceres <[email protected]>
Closes #125
The following tasks have been completed:
Implementation commitment:
Documentation and checks
Preview | Diff