Add ability for nested element's to specify their owner's element type #16133
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
In the
NestedElementTrait
the implementations ofgetOwner()
andgetPrimaryOwner()
have a call toElements::getElementById()
currently this is hard-coded to passnull
to the element type. This makes sense as there is no knowledge in this class of what the owner's element type would be.Unfortunately, in certain scenarios this can cause an n+1 query issue with many duplicated (get element type) queries.
This PR adds the
$ownerElementType
property to trait. This property is useful for those instances where the nested element already knows what its owner's element type is. This is applicable in the case of variants in Craft Commerce.In Commerce the
getOwner()
andgetPrimary()
methods from the trait have been overridden so that the element type can be specified (this greatly improved performance). With this PR this code can be removed and replaced with an implementation of the new property:There was consideration to note adding the property but instead add an argument to both the
getOwner()
andgetPrimaryOwner()
methods as this could make things more flexible. But this felt like more of a change and greater scope for it to be a breaking change (based on developers who may have implemented/overridden the methods already).