How does getContent() and IHubContent relate to other parts of the API that use IModel?

[tomwayson]

Currently getContent() is used to fetch all the data needed to display the content (for example in the Hub app's content views) and return the content as IHubContent.

Other functions like getInitiative() are currently used in other contexts like fetching the item/data in order to edit them, or to render a site, etc. These functions typically work w/ an IModel (i.e. item and data), which is effectively a subset of IHubContent. They sometimes do other things like apply data migrations that might not need to be done in a display only context.

We should have a wholistic strategy around these seemingly duplicative yet perhaps distinct sets of functions so that it's clear when to use one or the other, or perhaps combine them instead.

[drewdaemon]

I think the referenced issue #417 is on the right track (no surprise since I wrote it 😂).

The various type-specific migrations are currently written around fetching an IModel and are already in wide use in opendata-ui (e.g. getSite, getPage, getInitiative). That's why I think it makes sense to make getContent compatible with that system so that getting an IContent in one of those contexts doesn't require either rearchitecting the system to expect IContents or introducing redundant XHRs.

getContent() is used to fetch all the data needed to display the content

I think that is exactly the guideline that should be given. We'll never be using an IContent to update an item since

• all the current update APIs expect IModels and refactoring would be a massive effort
• the getContent API unifies the Portal and Hub APIs which makes sense for requesting and displaying, but updates will only ever happen to the Portal API

Would love to hear other thoughts as well.