Closed nytamin closed 1 year ago
Attention: 35 lines
in your changes are missing coverage. Please review.
Comparison is base (
18a2ee0
) 79.60% compared to head (ceaed83
) 81.32%.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
By default, I've set all return-data types to be undefined, since most where missing data-deserializers for them anyway.
@nytamin Wouldn't unknown
instead of undefined
result in a slightly better development experience for the consumers of the library?
@nytamin do you want to just merge this? Like I said, my last point is regarding the callback in the constructor but I'm not convinced either solution is better.
Yeah I'll go ahead and merge it then, I we come up with something better we can adress that later.
What kind of change does this PR introduce? (Bug fix, feature, docs update, ...) Add types to return data
What is the current behavior? (You can also link to an open issue here) return data was alwas typed to be
string[]
What is the new behavior (if this is a feature change)?
Return-data can now be strictly typed, so consumers can use it without having to manually parse the data.
By default, I've set all return-data types to be ~undefined~
unknown
, since most where missing data-deserializers for them anyway. For the ones that do have deserializers, I've set the return type to equal the deserialized data.