Refactor Status tag styles into UI component

Is your proposal related to a problem?

We currently have a “status tag” component as reusable CSS styles that are copy-pasted with the relevant HTML across the admin.

Describe the solution you’d like

This feels like a good candidate to refactor to a UI component, this is an approach where we use a template tag to abstract away the HTML.

This shouldn’t change the component’s rendering in any way, just how it’s included in different places (and introduce a way for us to test the variations more easily in Storybook). For example, we will not adjust the class names, even though these are somewhat confusing.

Requirements

• Create a new shared template partial (wagtail/admin/templates/wagtailadmin/shared/status_tag.html)
• Create a new template tag that uses this partial in wagtail/admin/templatetags/wagtailadmin_tags.py
• Ensure the template tag works with the classname kwarg
• Add a Storybook stories for different variations of this new component ( similar to wagtail/admin/templates/wagtailadmin/shared/header.stories.tsx)
• With a template partial in the shared folder for us to {% include %} where needed (update all locations)
• Ensure that the styleguide is also updated to use the new template partial wagtail/contrib/styleguide/templates/wagtailstyleguide/base.html

Additional context

• The help_block is a good example of how this has been done before https://github.com/wagtail/wagtail/blob/main/wagtail/admin/templates/wagtailadmin/shared/help_block.html & https://github.com/wagtail/wagtail/blob/main/wagtail/admin/templatetags/wagtailadmin_tags.py#L1059-L1063
• Current primary SCSS https://github.com/wagtail/wagtail/blob/main/client/scss/components/_status-tag.scss
• Secondary class re-use https://github.com/wagtail/wagtail/blob/main/client/scss/components/_listing.scss
• See also https://github.com/wagtail/wagtail/blob/main/client/scss/layouts/_report.scss#L11
• It may be really tricky to do this one wagtail/admin/templates/wagtailadmin/shared/page_status_tag.html (we may need to put the link inside the status tag or the other way around
• Follow up items (once this is done) - we should refactor to update the classes to align with w-status-tag and use BEM classes for the primary & disabled variants.

[lb-]

@salty-ivy I have put some comments on the PR but I think it would be best to start with the non-page status ones (the ones that use spans for the 80% use case).

If you search through the code for status-tag you will find about ~20 files that are quite simple status-tag variants, a span with a classname and some content inside.

I think it’s best we cover this first - and then revisit the more complex ones later. Namely wagtail/admin/templates/wagtailadmin/shared/page_status_tag.html - which uses a link & wagtail/admin/templates/wagtailadmin/shared/page_status_tag_new.html - which is a completely different approach using tailwind classes & tooltips.

Below is an example of how I anticipate we would use the generic status tag template tag, just calling it status probably makes more sense.

Example - page-title-cell

wagtail/admin/templates/wagtailadmin/chooser/tables/page_title_cell.html https://github.com/wagtail/wagtail/blob/da90061ca83170bd1da1c7ca77106690e21f7f49/wagtail/admin/templates/wagtailadmin/chooser/tables/page_title_cell.html#L9-L11

New usage

        {% if column.show_locale_labels and page.depth == 2 %}
            {% status classname="status-tag--label" %}{{ page.locale.get_display_name }}{% endstatus %}
        {% endif %}

Example - page history

wagtail/admin/templates/wagtailadmin/pages/history.html https://github.com/wagtail/wagtail/blob/da90061ca83170bd1da1c7ca77106690e21f7f49/wagtail/admin/templates/wagtailadmin/pages/history.html#L37-L44

New usage

                            {% if entry.revision %}
                                {% if entry.action == 'wagtail.publish' %}
                                    {% if entry.revision_id == page.live_revision_id %}{% status classname="primary" %}{% trans 'Live version' %}{% endstatus %}{% endif %}
                                {% elif entry.content_changed %}
                                    {% if entry.revision == page_latest_revision %}{% status classname="primary" %}{% trans 'Current draft' %}{% endstatus %}{% endif %}
                                    {% include "wagtailadmin/pages/revisions/_actions.html" with revision=entry.revision %}
                                {% endif %}
                            {% endif %}

Example template tag code

In wagtail/admin/templatetags/wagtailadmin_tags.py you will be able to see how we can easily create these block/endblock style template tags (using BlockInclusionNode). Below is a rough bit of working code (without classname support).

class StatusTagNode(BlockInclusionNode):
    template = "wagtailadmin/shared/status_tag.html"


register.tag("status", HelpBlockNode.handle)
# register.tag("status_tag", HelpBlockNode.handle) OR status_tag

[lb-]

@salty-ivy good question, I might need to defer to @thibaudcolas as to the long term plan here but here’s my best guess.

From the looks of these, they are a specific usage of the status tag to show the page’s live status only.

So I think that page_status_tag would end up using the new component you create.

Then… The new one is a new design that uses Tippy for the same purpose. So I guess a long term approach would be to adopt the new design for the status tag generic component in the future. However, Tailwind makes this a bit more complex, not sure where we are heading with this approach as we are yet to provide a clear direction for new Css.

Nonetheless, I think that this issue does not conflict with those templates, the non-new one would just adopt the generic template tag.

Hope that makes sense

Links

• https://github.com/wagtail/wagtail/blob/main/wagtail/admin/templates/wagtailadmin/shared/page_status_tag.html
• https://github.com/wagtail/wagtail/blob/main/wagtail/admin/templates/wagtailadmin/shared/page_status_tag_new.html