Hygraph schema structure simplifications

[paales]

Describe the feature you'd like to request

We'd like to simplify the Hygraph schema by leveraging a 'Variant' system instead of separate models for rows. This is an extension of #1912

Describe the solution you'd like

#1912 (comment)

With the current introduction of the Hygraph schema migration system we can start assuming the Hygraph schema exists in a certain format. We can assume the Page and DynamicRow components exist, this means that queries do not need to be in the example directory, but can be moved to a hygraph-content package or something (for now we can re-use the old graphcms-ui package).

The goal of the hygraph-content package should be: Make sure the schema is locked for the current models except for specific project specific implementations.

Asset (alt field)
DynamicRow
Page
PageLink
RowColumnOne (to be renamed to RowText)
RowLinks
Footer (to be renamed to Settings)
Components:

AND
Number
OR
Text
Enums:

DynamicRowConditionNumberOperator
DynamicRowPlacement
MetaRobots
RowLinksVariants
RowProductVariants
And assume the following Row components are 'project specific' (need to be kept in the examples directory):

RowBlogContent (to be migrated to RowText)
RowButtonLinkList (already deprecated)
RowColumnThree (to be deprecated)
RowColumnTwo (to be deprecated)
RowContentLinks (already deprecated)
RowHeroBanner (to be deprecated, replace with a variant on RowLinks)
RowQuote (to be deprecated, replace with RowText with a blockquote)
RowServiceOptions (to be deprecated, replace with a variant on RowLinks)
RowSpecialBanner (to be deprecated??)
Usps (to be deprecated??, replace with RowLinks variant?)
This of course is a way bigger project than the current implementation here, but it sets the changes that need to be made before the next major release.

---

After this comment we've had further discussions to simplify this even more, if we'd add an Asset field to RowLinks we could use it for even more cases.

[paales]

Also after this simplification we'd like to offer a declarative Hygraph schema so we can build libraries instead of keeping everything locally.

[paales]

Useless RowProduct entries

In the above post we didn't mention the RowProduct model, which is a bit of an odd one, because it requires external data to be passed for the row to actually display something useful.

The RowProduct used for a product are fairly empty as they only use the title of the RowProduct and nothing else, all other information is provided by the actual product.

Non product misusages

And second it isn't really a component that only renders information about a product, because it is also used to render information about categories on the homepage (home-product-backstory and home-swipable). So in it's current form it is more a RowMagentoProductOrCategory.

Although this being the case, there currently is no way to define which category or product is used to render a RowProduct.

The product page currently has a <ProductPageDescription /> which isn't rendered using RowProduct, and it also has USPS's which are a separate model.

Possible solutions

Create a RowReference model which allows you to create a reference to an external entity.

• internalName: Only used for internal title
• reference: Url path for a category or the url_key of a product.
• variant: ???
• title optional: If not provided, it will use the product/category name/title.
• copy optional: If not provided, it will use the product/category description.

The actual data loading happens on the next.js side. Although Hygraph supports federated content, it can not do so transparently (it prefixes everything so all our fragments and code can't be used to query information that way).

[paales]

Rows are scoped to a single RowRenderer

Currently we are limited in scope where to put Hygraph content: We have a defined RowRenderer in a single location and we are able to influence this location, but not other locations like:

• Before header
• After header
• After footer
• Before footer
• In add to cart block
• In menu location when opening a certain navigation item.

It might be interesting to explore more size render sizes:

• row: current Row renderer
• row-small: Store messages like Feature/store message #1881
• block: used in add to cart block or menu

Proposed solution

• Add a section field to the Dynamic Row model, so we can add content to specific sections on the website.
• Add the RowRenderer to the LayoutNavigation beforeHeader prop.
• Create a separate renderer which has size 'row-minimal'

[paales]

• RowText variant: Store message / banner
• RowText variant: contained
• RowText variant: default (maxWidth: 960px)

[paales]

Renamen Dynamic Row fields:

• internalLabel: "Internal Label (Required, Unique, Title): Label used for identifying this dynamic row configuration within the CMS system."
• row: "Row (Required): Reference to a content row that will be displayed on the website."
• relativePosition: "Relative Position (Required): Specifies the position of the row relative to the specified location [AFTER, BEFORE, REPLACE]."
• relativeTo: "Relative To (Optional): Specifies the location (either a specific row or the beginning/end of a section) where the row will be placed. If left blank, the row will default to the start or end of the specified section."
• section: "Section (Required): The page section where the row will be rendered [MAIN_CONTENT, ABOVE_HEADER]."
• conditions: "Conditions (OR): At least one of these specified conditions must be met for the row to be displayed."