-
-
Notifications
You must be signed in to change notification settings - Fork 184
Conversation
Co-authored-by: Enzo Innocenzi <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is an awesome PR, thanks! One remark on attribute usage, but that's all.
Thanks @brendt! |
Thanks! Tagged here: https://github.com/spatie/data-transfer-object/releases/tag/3.6.0 |
Without looking into the implementation...Does this work as an additional mapping? I mean, does it ignore the mapping if the array I use for initialization already contains the specified attribute? Because I would like to fill in a field from a separate location as fallback so to say. I validate accordingly that either one or the other can exist, but I want to have it only at one place in the DTO. Is this possible via mapping feature? |
Description
This pull request adds the ability to map DTO properties from source properties with different names.
This approach goes against the philosophy of doing a
1:1
mapping of DTOs, but it is undoubtedly helpful in the several cases that I present below.Use cases
1. Renaming a property when we have no control on the source data and/or for more clarity
2. Mapping a nested property without using an additional DTO
3. Mapping properties from an indexed array
Notes
This PR only requires the addition of a
resolveMappedProperty()
method inDataTransferObjectProperty
.However, handling the dot notation requires two additional array helpers (
Arr::get
andArr::accessible
). (Arr::get
has been simplified as default closure values are useless here.)Despite the addition of these two methods, this PR is still lightweight but would significantly improve the DX for some cases without any significant constraint.
I'm open to change the name of the attribute if
MapFrom
doesn't suit you.