Open tomwayson opened 3 years ago
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
IModel
s and refactoring would be a massive effortgetContent
API unifies the Portal and Hub APIs which makes sense for requesting and displaying, but updates will only ever happen to the Portal APIWould love to hear other thoughts as well.
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 asIHubContent
.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
anddata
), which is effectively a subset ofIHubContent
. 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.