Remove the need for `article_list` and `article_nav` components

[teneightfive]

Similar to PR #311 this consolidates the use of some of our components on the frontend. We were previously using article_* components to render parts of the surgery guide. This PR allows the same visual representation to be achieved using markdown and some added attributes.

The downside is that we are now using more instances of class names within markdown to render things like in-page anchor navigation. This means it is harder to update the structure to these without having to edit content and could be dangerous moving forward.

We need to find a more robust way to handle internal page navigation and remove the added overhead of adding classes and attributes to text content for presentation and analytics tracking.

Question

I'm not sure I'm comfortable with continuing with hard coded in-page navigation. I think it's something we need to address before we move to content being served from the content store rather than end up with lots of instances of hard-coded class names and attributes in that data store.

What's our stance on markdown filters now? I know we removed them for things like callouts to give us greater flexibility on what goes inside them but when it comes to things like special lists, for example cross/tick or numbered in-page navigation links, do we want to use special markdown syntax to render those? Or do we want to use a new component?

[marcofucci]

Agree with hardcoded links, we should fix that asap.

Re. custom markdown filters, I'm OK with keeping those simple ones, it doesn't make sense to use new components.

The tests are failing.

[teneightfive]

@marcofucci yep, agree that we shouldn't use custom markdown syntax for what we're defining as components but think for things like special lists it might make sense.

That being said, these lists are all to do with in-page navigation so there's probably a better solution than still hardcoding links and using a special list syntax.

One option is to create an automatic in-page navigation using second level headings for example. But this does give less flexibility when it comes to a difference in naming between link and heading or choosing not to add a link to a specific section.

[teneightfive]

@tyom with markdown-it TOC I think it needs to be referenced in the same markdown file as the contents. Seeing as we're splitting these out into multiple components it might not be as easy.

But the bigger question there is whether we want to put the constraint in that content designers can't control the text of that TOC and which sections to link to. Using TOC it will generate links to each heading at a certain level.

[tyom]

with markdown-it TOC I think it needs to be referenced in the same markdown file as the contents. Seeing as we're splitting these out into multiple components it might not be as easy.

Yeah, I realised that. Tricky.

But the bigger question there is whether we want to put the constraint in that content designers can't control the text of that TOC and which sections to link to. Using TOC it will generate links to each heading at a certain level.

We'll have to think harder on this one and come back to it later to try out a few ideas.