ConnectApi class hierarchy

[Xander Victory]

https://developer.salesforce.com/docs/atlas.en-us.apexref.meta/apexref/apex_connectapi_input_messageSegmentInput.htm

It seems these classes in my OST don’t have the superclass marked, so the editor doesn’t like putting them in a single list (though it deploys fine), showing Expected type ConnectApi.MessageSegmentInput; found ConnectApi.TextSegmentInput on line 6

‌

ConnectApi.AnnouncementInput input = new ConnectApi.AnnouncementInput();
input.body = new ConnectApi.MessageBodyInput();
ConnectApi.TextSegmentInput textSegmentInput = new ConnectApi.TextSegmentInput();
textSegmentInput.text = 'some text here';
input.body.messageSegments = new List<ConnectApi.MessageSegmentInput> {
        textSegmentInput
};

‌

‌

[Scott Wells]

Fix committed for inclusion in the next build:

Once the next build is installed, application of the fix will of course require OST regeneration.

[Eric Kintzer]

this could be related as the following generates a “cannot resolve symbol”

ConnectApi.FeedItemInput feedItemInput = new ConnectApi.FeedItemInput();
feedItemInput.feedElementType = ConnectApi.FeedElementType.FeedItem;

since FeedItemInput class is a subclass of ConnectApi.FeedElementInput

‌

[Scott Wells]

I just did a full audit of all documented type inheritance relationships in the ConnectApi namespace and found quite a few that weren't properly represented (including the one in your most recent comment). I've addressed all that I could find...which was a bit of a challenge given that the documentation can be...unwieldy at times. That'll all be included in tomorrow morning's build.

[Scott Wells]

Delivered in 2.1.7.9. I also incorporated bundled API documentation for the ConnectApi namespace. One thing I did notice is that the value object properties are all being reported as type Object by the Tooling API. This is also true in a few other cases where I've added explicit typing for those properties as part of OST generation. I can do the same here, but we're talking about thousands of untyped properties given the number of classes in this namespace, so I'll need to figure out some way to do it that's not 100% manual. That will have to wait for a future build. For now, though, the type inheritance relationships should be correct.

[Scott Wells]

Well, the good news is that with a bit of creative scripted doc scraping, I've added strong typing to the fields all of the documented value objects in the ConnectApi namespace that are reported by the API as being type Object. That actually covered over 2,000 distinct fields The bad news is that because the ConnectApi namespace's type documentation is incomplete, there are still about that same number that are still going to be just Object because there doesn't seem to be any authoritative source for their data types, even in the form of online docs.

I'll include what I have in next week's build as it definitely helps with the fidelity of the APIs in that namespace, but I hate that it still leaves such a large number of untyped fields. Sigh...

[Eric Kintzer]

Great task for Daniel Ballinger to take on now that he’s joined SFDC

[Scott Wells]

Okay, today I did a little script-fu and some serious abuse of the limits in one of my orgs to derive data types for the other untyped fields in the ConnectApi namespace. There are still a handful that are untyped, but it's because they're reported by the Salesforce Tooling API (albeit untyped) but when you try to reference them, it says they were removed in older API versions. Starting with the next release--which will be next Monday and will include Summer '21 / API v52.0 changes as well--IC2 should include a very high-fidelity version of the ConnectApi types.

[Xander Victory]

Legend!