Expose the Delivery API CLR type

[vsilvar]

Prerequisites

• I have added steps to test this contribution in the description below

Currently it's not possible to determine the delivery API type of a property without the use of reflection.
The use case for such a feature is to transform the swagger so it returns the proper document types response models, similar to Umbraco's models builder.
(You can check it here: https://github.com/ByteCrumb/Umbraco.Community.DeliveryApiExtensions)

Example of the code that is currently necessary:

private static readonly FieldInfo? ConverterField = typeof(PublishedPropertyType).GetField("_converter", BindingFlags.NonPublic | BindingFlags.GetField | BindingFlags.Instance);
private static Type GetPropertyType(IPublishedPropertyType publishedPropertyType)
{
    // This needs to be done first to ensure the converter field is actually loaded
    Type modelClrType = publishedPropertyType.ModelClrType;

    return ConverterField?.GetValue(publishedPropertyType) switch
    {
        IDeliveryApiPropertyValueConverter propertyValueConverter => propertyValueConverter.GetDeliveryApiPropertyValueType(publishedPropertyType),
        _ => modelClrType
    };
}

This PR exposes the necessary properties.
It's technically a breaking change as a property was added to IPublishedPropertyType.

[github-actions]

Hi there @vsilvar, thank you for this contribution! 👍

While we wait for one of the Core Collaborators team to have a look at your work, we wanted to let you know about that we have a checklist for some of the things we will consider during review:

• It's clear what problem this is solving, there's a connected issue or a description of what the changes do and how to test them
• The automated tests all pass (see "Checks" tab on this PR)
• The level of security for this contribution is the same or improved
• The level of performance for this contribution is the same or improved
• Avoids creating breaking changes; note that behavioral changes might also be perceived as breaking
• If this is a new feature, Umbraco HQ provided guidance on the implementation beforehand
• 💡 The contribution looks original and the contributor is presumably allowed to share it

Don't worry if you got something wrong. We like to think of a pull request as the start of a conversation, we're happy to provide guidance on improving your contribution.

If you realize that you might want to make some changes then you can do that by adding new commits to the branch you created for this work and pushing new commits. They should then automatically show up as updates to this pull request.

Thanks, from your friendly Umbraco GitHub bot 🤖 🙂

[georgebid]

And, thank you for this one too! 💯 Someone on the core collabs team will review this soon.

[kjac]

Hi @vsilvar - thanks a lot for this. It looks great!

As you mention there is a little issue with breakage on the public IPublishedPropertyType interface. I'm sure this can be resolved with a default implementation of DeliveryApiModelClrType on the interface itself?

I'll give it a spin in the coming days 😄

[kjac]

Hi again @vsilvar,

This looks good 👍 I have left a few comments and a means to keep this from breaking the interface.

[vsilvar]

Hi @kjac
Thanks for having a look, I'll have check it out and address the feedback 👍

As for the default implementation to avoid the breaking change, I've initially refrained from doing so, as we can't implement it with a correct behavior. Any class that implements IPublishedPropertyType and doesn't override DeliveryApiModelClrType will behave incorrectly, and it might not be obvious that they should/need to implement DeliveryApiModelClrType as there's already a default implementation. (You might even consider it a bug 😅)
But if that's preferred over having a breaking changes, I can go ahead and change it as well.

EDIT: All comments should be addressed now, let me know if I missed any

[kjac]

Hi @vsilvar,

Thanks a lot for the updates. I'll get on them soon 😄

The default implementations at interface level is indeed less discoverable than the alternative, but we can't break things at interface level for a minor. The only alternative is to target V13 for this PR, and I believe you'd like this for V12?

[vsilvar]

Hi @kjac,
I think targeting v13 would be fine, specially if it results in a more maintainable solution 🙂

I'll leave that up to you, and already made a separate commit for the default interface implementation so it's easy to revert if we do target v13.

[kjac]

It's all good @vsilvar ... it's fine to include in V12, might come in handy for some.

V13 introduces another new property on the interface for explicit cache levels during property expansion, and that is also implemented as non-breaking in the same fashion: https://github.com/umbraco/Umbraco-CMS/blob/release/13.0/src/Umbraco.Core/Models/PublishedContent/IPublishedPropertyType.cs#L63

I'm fighting the build pipelines with this one. Soon as they stop acting up, I'll be able to give this a spin.

[kjac]

@vsilvar the builds are being a bit on the annoying side today.

Could I ask you to please update your fork and merge the contrib branch into this PR?

[vsilvar]

@kjac Sounds good 👍
Just merged contrib into the PR branch, let me know if anything else needed.

[kjac]

Looks great and tests out great too 😍

[kjac]

Good stuff @vsilvar 🥳

I'll cherry-pick this to V13 in the hopes it'll make it into 13.0. We don't know yet when the next V12 will be out, but by then this will be there too 😄

[kjac]

Cherry-picked in a4b4107

[vsilvar]

Sounds great, thanks @kjac!