You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
"content" here refers to everything other than the metric files themselves that varies by tenant: copy associated with metrics, what collections are active and what metrics they contain, copy for non-metric pages, etc. The content model, combined with a list of active metrics, comprises the source of truth for what should be displayed on any given page.
All of the data should live in JS objects that are part of the runtime bundle. There is no API server
The content associated with a particular piece of UI should be describable by standard types, e.g., (illustrative but not exhaustive) every Metric should have a Title, a Description, a Methodology
Standard page copy elements (e.g. titles, descriptions) should support arbitrary HTML such as links or multiple paragraphs. The API layer should transform this into something that can be safely rendered by React (using, e.g., react-html-parser).
There is a m2m relationship between collections and metrics; the content model should describe this and support lookups and traversals in both directions. The relationships are not completely arbitrary (i.e. they can be described at the type level) but they do need to resolve to tenant-specific instances (which may or may not be active or present for a given tenant). Given one or more collections we should be able to fetch their matching metrics, and vice versa.
Relationships between collections are limited to simple intersection for now.
The required granularity of content retrieval is still somewhat TBD, pending designs. Start with just fetching all fields related to a single "object" with a separate option to traverse relationships between objects. Because content is synchronous and already in memory, "over-fetching" is probably not a significant cause for concern at this point.
The API surface should be thoroughly tested
Refer to design doc and PRD, as well as existing ND site, for a fuller rundown of what content is supported and already present. Start by porting existing ND content.
The text was updated successfully, but these errors were encountered:
Requirements for basic content modeling API:
Refer to design doc and PRD, as well as existing ND site, for a fuller rundown of what content is supported and already present. Start by porting existing ND content.
The text was updated successfully, but these errors were encountered: