feat: add kind arg to encode/decode interface #75
Conversation
In the case of using specialized schema validation/encoding/decoding we would like to have some context on the data being passed to serialization functions which would allow us to make a judgement on which specialized schema [validator|decoder|encoder] to use. This is a non-breaking change.
| @@ -1,6 +1,6 @@ | |||
| export type Serialization = { | |||
| encode: (value: unknown) => string; | |||
| decode: (string: string) => unknown; | |||
| encode: (value: unknown, kind: any) => string; | |||
There was a problem hiding this comment.
Could we future-proof the syntax? Let’s make the second parameter an object for possibilities to expand it in the future, and let’s include the id while we’re at it for symmetry.
export type Serialization = {
encode: (value: unknown, details: { kind: string, id: string }) => string;
decode: (string: string, details: { kind: string, id: string }) => unknown;
};ensure future extensibility by making the second arg an object
abelino
force-pushed
the
feature/add-kind-arg-to-serde-fns
branch
from
1f479de
to
979821f
Compare
abelino
requested review from
amclain,
hecontreraso and
nateq314
as code owners
| @@ -100,7 +107,7 @@ export function makeWsProtocolAdapter( | |||
| id, | |||
| pushId, | |||
| lastSeenRevision, | |||
| value: serialization.encode(value) | |||
| value: serialization.encode(value, { id, kind: String(kind) }) | |||
There was a problem hiding this comment.
@denis-sokolov is this correct? I haven't had time to dive too much into some of the type definitions but the type checker mentioned kind could be a few other type other than a string. Is converting to a string here ok?
There was a problem hiding this comment.
kind variable comes from the definition of our type, so its keyof Domain.
Technically we could type it more strictly and precisely, but we’re doing very dynamic things and as long as our API is clean type-wise, it’s not a big deal. You’ll find a few as any in this file, too.
Let’s leave it like this for now and maybe later we’ll tighten up the types.
|
thanks @denis-sokolov for the review |
In the case of using specialized schema validation/encoding/decoding we
would like to have some context on the data being passed to
serialization functions which would allow us to make a judgement on
which specialized schema [validator|decoder|encoder] to use.
This is a non-breaking change.