Using MapOutputName without affecting TypeScript

[ragulka]

In our project, we'd like to use camelCase on the frontend and in our Data objects, but still use snake_case in the models/database.

For this, I've created something like the following:

#[TypeScript]
#[TypeScriptTransformer(DataTypeScriptTransformer::class)]
#[MapOutputName(SnakeCaseMapper::class)]
class CreateProductData extends Data {
    
    public string $name;
    public string $variantName;
}

It works great when calling $data->toArray(), but the issue is that DataTypeScriptTransformer will also use snake_case property names for the TS definition, resulting in this:

export type CreateProductData = {
  name: string
  variant_name: string // not what we want - should be `variantName`!
}

This is an issue, because we do not use snake_case on the frontend - this DTO is used specifically to map camelCase frontend data to snake_case for the backend, when creating a new product.

Is there any way to ignore the mapped output names when transforming the data class for the frontend?

[rubenvanassche]

At the moment no, I think in a next release we probably want to be able to attach tags to MapOutputName and MapInputName, something like this:

#[MapOutputName(SnakeCaseMapper::class, 'array')] -> would then be used to map names in array responses

Let's say you've got camel case names and want snake typescript names:

#[MapOutputName(SnakeCaseMapper::class, 'typescript')]

By default when adding no tags everything would be mapped:

#[MapOutputName(SnakeCaseMapper::class)]

This would also solve issues where when mapping data to the database models also could specify its casing while having another casing for requests:

#[MapOutputName(SnakeCaseMapper::class, 'eloquent')]
#[MapOutputName(CamelCaseMapper::class, 'requests')]

It would be cool if people would be able to define their own mapping tags like

#[MapOutputName(SnakeCaseMapper::class, 'ios-app')]

Which could be used with:

$data->transform(TransformContextFactory::create()->mapOutputNamesFor('ios-app'))

I'll add it to my list for data v5 but would certainly accept PR's so this can be added in earlier!

[ragulka]

Thanks, those would definitely be helpful additions!

Related to the issue I described, I also noticed that when using #[MapInputName(SnakeCaseMapper::class)], the manual validation rules need to be defined with snake_case keys, rather than camelCase. If they're defined in camelCase, the rules are never applied.