Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Content Modeling for Spotlight #225

Closed
hobuobi opened this issue Oct 13, 2020 · 0 comments · Fixed by #258
Closed

Content Modeling for Spotlight #225

hobuobi opened this issue Oct 13, 2020 · 0 comments · Fixed by #258
Assignees
Labels
Team: Glitter Issues/Epics owned by Glitter (public data efforts)

Comments

@hobuobi
Copy link

hobuobi commented Oct 13, 2020

Requirements for basic content modeling API:

  • "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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Team: Glitter Issues/Epics owned by Glitter (public data efforts)
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants