-
Notifications
You must be signed in to change notification settings - Fork 623
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
feat(cbor/unstable): introduce @std/cbor
#5909
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #5909 +/- ##
==========================================
- Coverage 96.75% 96.55% -0.21%
==========================================
Files 509 530 +21
Lines 39175 40483 +1308
Branches 5795 6067 +272
==========================================
+ Hits 37905 39087 +1182
- Misses 1228 1352 +124
- Partials 42 44 +2 ☔ View full report in Codecov by Sentry. |
I wonder if these need to be classes when they both don't have any instance states. How about making them just |
Sure. I was trying to mirror the structure of |
Side note: |
@BlackAsLight, could you please draft this PR and un-draft once ready for us to review? |
Is there a way I can get the Sentry bot to update or create a new report on what lines are missing? |
Coverage diff of this PR should be visible in this page https://app.codecov.io/gh/denoland/std/pull/5909
There are mixed naming styles, We'd like to export a single API from a single file. Can you split files based on exported APIs
|
That page hasn't gotten updated in like 5 days now, which is why I asked.
The difference in naming style is intentional. The "Encoder" and "Decoder" ones are TransformStreams that actually do the work of converting, while the "Decoded" ones are ReadableStreams that act as a simple wrapper so the user of the lib is able to know what type of chunks to expect. I did explore the idea of having the "Decoded" ones also be TransformStreams and handling the logic of conversion, but the logic there seemed too complicated as you don't know how far to go until you've actually decoded it. I also explored the idea of having the other "Encoder" ones (i.e.
That is a lot of files, but I can do that. |
cbor/types.ts
Outdated
* Specifies the encodable value types for the {@link CborSequenceEncoderStream} | ||
* and {@link CborArrayEncoderStream}. | ||
*/ | ||
export type CborInputStream = |
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.
How about renaming this to CborStreamInput
as this itself is not always a stream, but an input for the stream?
The same suggestion could also apply to:
CborMapInputStream
->CborMapStreamInput
CborOutputStream
->CborStreamOutput
CborMapOutputStream
->CborMapStreamOutput
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'll also work on this change
I'll move the files |
The user isn't meant to create instances of the decoded streams themselves, but they do need access to them to be able to figure out what type they have. For example with an Edit: maybe a Boolean function instead could be used instead by the user? |
|
@BlackAsLight |
Looks good to me |
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.
LGTM
@std/cbor
@std/cbor
Closes #5479
This pull request introduces a CBOR implementation based off the RFC 8949 spec from scratch. It introduces functions like
encodeCbor
,encodeCborSequence
,decodeCbor
, anddecodeCborSequence
, and aCborTag
class to provide additional semantic information.It also introduces streaming versions called:
CborSequenceEncoderStream
CborByteEncoderStream
CborTextEncoderStream
CborArrayEncoderStream
CborMapEncoderStream
CborSequenceDecoderStream
CborByteDecodedStream
CborTextDecodedStream
CborArrayDecodedStream
CborMapDecodedStream
It should be noted the different naming convention used between the "encoder", "decoder" and "decoded". The "encoder" and "decoder" classes are TransformStreams, while the "decoded" classes are ReadableStreams and act merely as a way for the user to figure out what type they have.
Due to the way streams work, if one of the "decoded" streams are yielded then they'll need to either be entirely consumed or cancelled before the next value will be yielded. This should be noted when using things like
Array.fromAsync
. Such a function would work only if you can guarantee that no value yielded will be one of these "decoded" streams. If such a value is yield in such a function then it will hang indefinitely.Example 1
Example 2
Example 3