Add Storybook links to the docs site for Web Components and RDS Storybook

[itsmedavep]

This addresses the desire to have the docs site link to the WC and Reac Storybooks.

This only covers the docs pages where we have Storybook stories for both the WC and React versions as a first step in the process.

Additionally, this adds the Storybook svg icon and colors it with a class by wrapping it in a <span>.

That was necessary because DeCap descriptions use >- style markdown and if we used the cfpb-icon colorization natively it would hit a YAML parsing error. (it works fine in the WC reference docs page because it lives outside of a description)

That means it covers:

alerts
buttons
expandables
filter tags
taglines

yarn start and verify there are now links to WC and React Storybooks.

Additions

Removals

Changes

Testing

Screenshots

Before	After

Notes and todos

Checklist

• PR has an informative and human-readable title
• Changes are limited to a single goal (no scope creep)
• Code can be automatically merged (no conflicts)
• Code follows the standards laid out in the CFPB development guidelines
• Passes all existing automated tests
• Any change in functionality is tested
• New functions are documented (with a description, list of inputs, and expected output)
• Placeholder code is flagged / future todos are captured in comments
• Visually tested in supported browsers and devices (see checklist below 👇)
• Project documentation has been updated
• Reviewers requested with the Reviewers tool ➡️

Testing checklist

Browsers

Check the current browser support cutoff list for browsers that are advisable
to prioritize for testing.

Accessibility

• Keyboard friendly
• Screen reader friendly

Other

• Is useable without CSS
• Is useable without JS
• Flexible from small to large screens
• No linting errors or warnings
• JavaScript tests are passing

[itsmedavep]

iconography page	alerts page
buttons page	expandables page
filter tags	taglines page

[niqjohnson]

High level, I wonder if we can refactor this a little to centralize all the markup for the links in one spot so we don't have to repeat it on every page. Take this with a grain of salt since I'm out of practice with the Design System, though. Can we move the markup to variation-content.html, something like:

{% if page.storybook_links and page.storybook_links.size > 0 %}
    <ul class="m-list m-list--links">
        {% for storybook_link in page.storybook_links %}
            <li class="m-list__item">
                <a class="a-link a-link--jump" href="{{ storybook_link.href }}">
                    [storybook icon goes here]
                    <span class="a-link__text">{{ storybook_link.text }}</span>
                </a>
            </li>
        {% endfor %}
    </ul>
{% endif %}

Then we'd have a storybook_links field in the markdown files that can contain any number of links in it (the content of which would be the link text and the link URL). That would probably have to be hooked up to appear in Decap, too, right?

So it would be more upfront setup this way, but it would probably make it easier to add more links in the future (and would keep the markup in one spot if we ever need to change it).

What do you think?

[niqjohnson]

Can this be marked up as our standard link with icon component? If we want to go that route, I think we can get rid of the external link icon at the end and use just the Storybook icon as the icon (since these links all still point to cfpb.github.io). I think we can get around having to wrap the icon in a span if we move the markup to a template instead of in the markdown.

[itsmedavep]

A couple of things

1. I tired to match the concept that Jenn had closely, if we want to move away from that I think what you suggest here makes sense.
2. I was trying to use web components for this since we really should be moving off the legacy components IMO.
3. Given that, if we loose both icons in favor of only the Storybook one it probably would become <cfpb-link href="#" icon-left="Storybook">This is a link</cfpb-link>

[niqjohnson]

Can this be marked up as our standard link list component? Semantically I think that makes sense, but I'm not sure if it'll throw anything off in the layout.

[itsmedavep]

It can and probably should but I believe it introduced layout issues when I tried to use the WC cfpb-list component. I can revisit.

https://cfpb.github.io/design-system/components/reference-for-custom-elements#list

EG:

<cfpb-list>
  <cfpb-link><a href="#">Item 1</a></cfpb-link>
  <cfpb-link><a href="#">Item 2</a></cfpb-link>
  <cfpb-link><a href="#">Item 3</a></cfpb-link>
</cfpb-list> <cfpb-list gap="compact">

[itsmedavep]

High level, I wonder if we can refactor this a little to centralize all the markup for the links in one spot so we don't have to repeat it on every page. Take this with a grain of salt since I'm out of practice with the Design System, though. Can we move the markup to variation-content.html, something like:

{% if page.storybook_links and page.storybook_links.size > 0 %}
    <ul class="m-list m-list--links">
        {% for storybook_link in page.storybook_links %}
            <li class="m-list__item">
                <a class="a-link a-link--jump" href="{{ storybook_link.href }}">
                    [storybook icon goes here]
                    <span class="a-link__text">{{ storybook_link.text }}</span>
                </a>
            </li>
        {% endfor %}
    </ul>
{% endif %}

Then we'd have a storybook_links field in the markdown files that can contain any number of links in it (the content of which would be the link text and the link URL). That would probably have to be hooked up to appear in Decap, too, right?

So it would be more upfront setup this way, but it would probably make it easier to add more links in the future (and would keep the markup in one spot if we ever need to change it).

What do you think?

Yeah, that is an interesting question. We probably could do that. I think if we did we would probably want to use the Web Component version (so cfpb-link).

It would need to be hooked up in DeCap.

One thing to point out is that I consciously was avoiding making changes to DeCap with this PR. That was/is because of our DeCap woes. I didn't want DeCap's issues to sidetrack this from getting done.

Since right now DeCap's future is questionable, and there are bugs, I am not exactly sure what the right move would be for this.

Thoughts?