ICC-143 Adding Binary tipe in order to handle Buffer

[Garma00]

trafficstars

List of Changes

• Added Binary and BinaryFromArray types
• Added unit tests

Motivation and Context

In order to handle binary files (such as octet/stream responses) an io-ts type is needed

How Has This Been Tested?

Unit test

Screenshots (if appropriate):

Types of changes

• [ ] Chore (nothing changes by a user perspective)
• [ ] Bug fix (non-breaking change which fixes an issue)
• [x] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

• [ ] My change requires a change to the documentation.
• [ ] I have updated the documentation accordingly.

[pagopa-github-bot]

	Warnings
:warning:	Please include a Pivotal story at the beginning of the PR title (see below).

Example of PR titles that include pivotal stories:

• single story: [#123456] my PR title
• multiple stories: [#123456,#123457,#123458] my PR title

Generated by :no_entry_sign: dangerJS against 69d0a7d04a083a62e3ea518543f9d177691bce50

[gunzip]

I cannot make pull requests against this repository but, what about a refactor using standard io-ts types instead of custom quasi-typeguards methods?

https://gist.github.com/gunzip/bdfbbd5e3fbceeccacd96f5bbe064b15

(just double check expecially the encoding parts)

[gunzip]

I've update the gist to use identity for encoding in case that's what you want to. My concern with the current version are:

1. methods that return booleans should be typeguards instead
2. methods that return booleans must be prefixed with is or has
3. poor naming: Uint8ArrayValidator converts the input to a buffer, while the name suggest it's a read only op
4. missing usage of failure / success methods (ie. hardcoding [{ context: c, value: "Invalid Uint8Array" }])
5. mismatch between is and decode methods (ie. BinaryFromArray.is doesn't check that the buffer is not empty, while decode does)

[Garma00]

I cannot make pull requests against this repository but, what about a refactor using standard io-ts types instead of custom quasi-typeguards methods?

https://gist.github.com/gunzip/bdfbbd5e3fbceeccacd96f5bbe064b15

(just double check expecially the encoding parts)

I agree that this refactor looks more readable, the logic seems to be the same to me, I also checked with the unit test I have added, maybe the naming NonEmptyBufferFromArray it's better instead of BinaryFromArray at this point.

[gunzip]

Just note with the code in the gist you will decode from the unknown type (I don't know the context where these types will be used). This is fine if you actually expect anything from the input, but you may chose to be stricter and change, for example

export const BinaryFromArray = new t.Type<NonEmptyBuffer, Buffer, unknown>

to

export const BinaryFromArray = new t.Type<NonEmptyBuffer, Buffer, Array<number>>

This will prevent you to call BinaryFromArray.decode(foo) where foo can be undefined or null and moves the burden to do runtime and/o type checks to the caller.

Moreover, if you are going to decode from unknown you may want to try Buffer.fromhere and/or Array.from here and check for errors before calling the type guards.

[sonarqubecloud[bot]]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication