This PR builds on #510 (and subsequent bug fixes) to pretty dramatically improve the code layout of content functions in info pages. Here's the todo list:
[x] generateTrackInfoPage
[x] generateAlbumInfoPage
[x] generateFlashInfoPage
[x] generateGroupInfoPage
[x] generateArtistInfoPage
And the details:
We've changed a bunch of components to work when provided empty sets of data - for example a track list will generate without error even if you provide it an array of tracks that is empty. They now return blank content - generally through [html.onlyIfContent]: true on the top-level tag. This lets us still use those components as relations a lot more greedily, reducing logic in the actual page components!
We've made generateContentHeading return a tag that is [html.onlyIfSiblings]: true. This makes it nice and easy to integrate in content: rather than perform a manual blank check, just nest the heading and section content in a conditionless html.tags([...]). The heading will only show if the section content is non-blank! This combines with the above "blank if empty" changes super nicely.
Getting this to work right involved some investigation and bug-fixing for templates in stringified content in general, i.e. the template itself isn't onlyIfSiblings but its content is, and we need to be able to detect that. The fixes shouldn't affect performance at all and will probably enable better integration of templates (or rather their content) with funky html stringification features in general!
We've just given pages a single generateContentHeading relation, instead of one for each section. We clone it with .clone() before setting slots.
We've removed the awkward relations.sections / sec syntax used across most info pages. It was just a needless idiosyncrasy, born super early on in the development of content functions in general.
We've tidied most parts of info page content functions to use arrow function syntax, instead of statement blocks! These are a heck of a lot nicer to read and edit, and much easier to integrate with the reduced logic and tossed-away sec syntax.
These make info pages a bunch nicer to navigate and work with, and make them a lot more in line with other content functions. Good stuff!
This PR builds on #510 (and subsequent bug fixes) to pretty dramatically improve the code layout of content functions in info pages. Here's the todo list:
generateTrackInfoPagegenerateAlbumInfoPagegenerateFlashInfoPagegenerateGroupInfoPagegenerateArtistInfoPageAnd the details:
[html.onlyIfContent]: trueon the top-level tag. This lets us still use those components as relations a lot more greedily, reducing logic in the actual page components!generateContentHeadingreturn a tag that is[html.onlyIfSiblings]: true. This makes it nice and easy to integrate in content: rather than perform a manual blank check, just nest the heading and section content in a conditionlesshtml.tags([...]). The heading will only show if the section content is non-blank! This combines with the above "blank if empty" changes super nicely.onlyIfSiblingsbut its content is, and we need to be able to detect that. The fixes shouldn't affect performance at all and will probably enable better integration of templates (or rather their content) with funky html stringification features in general!generateContentHeadingrelation, instead of one for each section. We clone it with.clone()before setting slots.relations.sections/secsyntax used across most info pages. It was just a needless idiosyncrasy, born super early on in the development of content functions in general.secsyntax.These make info pages a bunch nicer to navigate and work with, and make them a lot more in line with other content functions. Good stuff!