Transform Keys

[dfidler]

Summary

Have a built-in method for transforming/replacing keys, both in collections and in validation rules.

Validation

I'd love to be able to transform the incoming keys in the request using a map or definition that transforms the keys as I need them to.

Example:

GIVEN controller method SomeRecordController::store(SomeRecordCreateRequest $request)
  AND 


SomeRecordCreateRequest::rules() 
{
  return [
    id     => 'required|number',
   'starts' => 'required|date|transform:starts_at',
   'ends'  => 'required|date|transform:ends_at',
  ];
}

WHEN Request C contains:
[
  id        => 1,
  starts    => // some Carbon Date A,
  ends      => // some Carbon Date B
]);
  OR Request D contains:
[
  id        => 1,
  starts_at => // some Carbon Date A,
  ends_at   => // some Carbon Date B
]);
  OR Request E Contains:
[
  id        => 1,
  starts    => // some Carbon Date A,
  ends      => // some Carbon Date B
  starts_at => // some Carbon Date X,
  ends_at   => // some Carbon Date Y
]);


THEN for each C, D and E, $request->validated() returns:

C => [
    id        => 1
   'starts_at'=> A
   'ends_at'  => B
];
D => [
    id       => 1
   'starts_at'=> A
   'ends_at'  => B
];
E => [
    id       => 1
   'starts_at'=> X
   'ends_at'  => Y
];

Illuminate\Support\Collection

Perhaps, less important (to me at least) is a built-in to transform the keys of a collection based on a supplied key map. So, for example:

GIVEN starting with Collection containing:

$collection = collect([
  id     => 1,
  starts => // some Carbon date,
  ends   => // some Carbon Date
]);

WHEN running:

$transformed = $collection->replaceKeys( [ 
  'starts' => 'starts_at',
  'ends' => 'ends_at,
]);

// $transformed becomes
[
  id        => 1,
  starts_at => // some Carbon date,
  ends _at  => // some Carbon Date
]

Reasoning

I have an SPA that has gone through several teams and developers and each of them have introduced their own "style" into my API. THe problem is that:

1. DB columns are always snake case
2. Resource classes have a mix of snake and camel case, sometimes in the same resource (depending on who implemented the feature)
3. Controller classes (which we're slowly migrating to "Laravel Action" (https://www.laravelactions.com/, which we feel are a better architecture than controllers + request classes) have a mix of snake, camel and seemingly random standards for input names.

The result is an API that looks like dog turd (in terms of standards).

We are refactoring the UI and API slowly over time, but it would be amazing if we could refactor small parts of the API at a time without introducing big changes with a ton of boilerplate code to make this work.

In general, this would lighten the changes necessary because we could modify the request to accept both a "starts" and "starts_at" input (which means the UI wouldn't break).

The API wouldn't care which one you supplied (it would simply respect that "starts_at" takes precedence over "starts" if they're both supplied) and the -$request->validated() would return the snake_case keyed array for easy use with the Model->fill() methods.

Thoughts?

[macropay-solutions]

Hi.
We implemented a similar feature but we didn't expose it under MIT license.
More details
https://github.com/macropay-solutions/laravel-lumen-crud-wizard-decorator

[shaedrich]

You can, however, already kinda do this:

$coll = collect([ 'a' => 1, 'b' => 4 ]);
$coll->mapWithKeys(fn($value, $key) => [ match($key) {
  'a' => 'c',
  'b' => 'z',
} => $value ]);
/*
Results in:
[
    'c' => 1,
    'z' => 4,
]
*/

It might look ugly at first but actually it's just your mapping array expressed as a match expression.

[dfidler]

Yes I'm familiar with that but it's that kind of ugly/unreadable boilerplate I'm trying to avoid and converting that into a Collection method of not only trivial, but also makes more code readable). And why replicate that code in many places when you can just add it to Collection?

Request objects require the reverse mapping, and all of our models have 3 resource classes which describe their level of detail: ID, List and Full - eg, UserIDResource, UserListResource, UserResource (each one extends the level above it,which massively improved our apps performance).

We have 25 controllers (4+methods each) and about 90 Resource classes. Not all of them need this kind of refactoring but imagine how gross that could be writing all of that boilerplate everywhere. It is a maintainability nightmare.

It's also much less readable...

Though in thinking thru it, maybe a Model-level mapping is better, which is automatically implemented in the resources and Request/validation routines.

Being able to define a key map, either at the model, resource or request/validation level is cleaner, more readable and more maintainable.

I wonder though, is this problem unique to our app?

[shaedrich]

I guess, this method would be quite neat to have 👍🏻

[macropay-solutions]

See also this https://github.com/jarektkaczyk/eloquence-mappable
This works at the model level.