Transform function type should, at least preserve the shape of the Data

[danielo515]

Hello, and again, thank you for this library. I noticed that the transform function signature makes working with it a bit hard, because the input value is typed as unknown but the expected return type is of data: https://github.com/pablo-abc/felte/blob/b007b7fddbf0b8ce0c99f73e410e407ec102a2d8/packages/common/src/types.ts#L262

This forces you to re-validate the entire think before you can do any work with it or even return it. I was wondering if it would be possible to, at least, preserve the shape and type each key value as unknown? That will probably make things easier. Not sure if such a type would be accurate though, so what are your thoughts about it?

Here could be one implementation example:

type NonValidated<T> = { [k in keyof T]: unknown}

type Obj = Record<string, unknown>;
type TransformFunction<Data extends Obj> = (values: NonValidated<Data>) => Data;

const trans: TransformFunction<{name: string, age: number}> = (values) => {
  const name = values.name //name is unknown
    // ^?
}

[danielo515]

After working with it, I also noticed another potential problem, and that is the need to return a valid type of Data. There are situations where it is impossible to parse the current set of inputs to a valid type, so having to return a type that conforms to the expected submit value is often impossible. This is one of the situations where a sum type or a compound type with a flag of it signaling if it is valid or not makes sense. Without this, you have to resort to coercions that will invalidate the type checking functionality of the libary.

[pablo-abc]

The reason why it is currently unknown is that, when making this feature, I assumed the source of your data could be almost anything. E.g. completely changing the shape of an object based on the current state of your HTML (or something external, like keeping some extra state outside of Felte).

While the basic use case for this is to transforms data types, you should also be able to completely re-shape the input into the data object you expect. Maybe a combination of inputs should translate to a single field on your data object, maybe you have some hidden inputs that are only useful for the client.

The type of Data in this case should represent the shape/types of how you want your data store to always be. This is why I enforce returning a valid type of Data. Whatever is returned will be what you read from the data store, so it has to conform to that type.

[danielo515]

Yes, I think it makes sense. The only downside is that you have to include a lot of logic to validate data that may not have changed, but I guess is an acceptable tradeoff.

On Tue, Sep 13, 2022 at 10:00 PM Pablo Berganza @.***> wrote:

The reason why it is currently unknown is that, when making this feature, I assumed the source of your data could be almost anything. E.g. completely changing the shape of an object based on the current state of your HTML (or something external, like keeping some extra state outside of Felte).

While the basic use case for this is to transforms data types, you should also be able to completely re-shape the input into the data object you expect. Maybe a combination of inputs should translate to a single field on your data object, maybe you have some hidden inputs that are only useful for the client.

The type of Data in this case should represent the shape/types of how you want your data store to always be. This is why I enforce returning a valid type of Data. Whatever is returned will be what you read from the data store, so it has to conform to that type.

— Reply to this email directly, view it on GitHub https://github.com/pablo-abc/felte/issues/164#issuecomment-1245893968, or unsubscribe https://github.com/notifications/unsubscribe-auth/AARKJWNGPIXYVWXDFPBWSRTV6DMNRANCNFSM54U2TVZA . You are receiving this because you authored the thread.Message ID: @.***>

--

https://danielorodriguez.com