Introduce another Transform type

[aleclarson]

Currently, the Transform type assumes I'm decoding an input value (e.g. a URL path parameter). Let's call this the input direction. Nothing is inherently wrong with this, but it makes for some awkward-reading code when using the Transform type for encoding an output value (e.g. a Redis value). You end up using Decode(…) to encode the value and Encode(…) to decode the value.

What if we had two transform types? Input and Output.

With Input(String()), we are receiving a string and decoding it into a value our code expects.

With Output(String()), we are sending a string and encoding it from a value our code produces.

The existing Encode() and Decode() functions, as well as the StaticEncode and StaticDecode types, should work with both as you would intuitively expect.

Interested to hear your thoughts!

[sinclairzx81]

@aleclarson Hi,

Interested to hear your thoughts!

I would actually be open to changing this, but would need to happen on a revision tick. I do think there is value in splitting Type.Transform() into two distinct functions (Input() and Output()) as the current Transform design is a bit clunky, but needs a updated design put forth to proceed with anything.

If I recall, there were type related aspects that informed the current Type.Transform() design, where the Encode() input type was derived from the Decode() output type when creating the transform. To support splitting into distinct functions, there would need to be some work done to ensure the static types line up as one would expect.

Would you be interested in drafting an example of what you had in mind? It should be possible using the current TypeBox infrastructure. Happy to discuss this more.

[sinclairzx81]

@aleclarson Hiya,

Might move this one into discussions as there isn't anything to action at this stage, but would generally need to focus on a design before implementation.

For what it's worth, I actually like the idea of splitting Decode / Encode up and possible deprecating Transform (as Transform mandates bi-directional transformation). There are cases where bi-directional transformation isn't possible (for example, where Decode might hash a value, there is no way to return to the original string on Encode). There are other cases too, but I think in general, by splitting Encode/Decode up (and possibly renaming to Input/Output) this would let users opt-in to bi-directional transformation only in cases where it applies, and this opt in aspect is very much inline with TypeBox's over arching design goals.

Will move to discussions, but very much open to continuing this thread. Also as of writing, TypeBox is being redeveloped almost from the ground up (a massive undertaking, for which I am currently 4 months into it) and there is room to change and improve the API in places which have proven awkward. I am very receptive to ideas on improving the API, and do think Transforms are one of those things that could be re-evaluated.

I look forward to further discussions.