Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Makes the code example an exported component #264

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

frankieroberto
Copy link
Contributor

This changes the design of the code examples component from this:

Screenshot 2024-11-11 at 00 41 15

to this:

Screenshot 2024-11-11 at 00 42 01

ie - the tabs are at the bottom, and the preview remains on top. This more closely aligns with the styled used by the GOV.UK Design System, and means you can see the preview and the HTML or Nunjucks code at the same time.

The 'Example' component is also moved from being just within the documentation site itself, to being exported with the GOV.UK Prototype Components package itself.

This means there could be a documentation page for the Example component itself, with examples, inception-style...:

Screenshot 2024-11-11 at 00 44 16

Code all needs tidying up and making more robust, but this is a first stab to see if it looks like a good idea or not...

Also changed the design to match the one used by the GOV.UK Design System website, so no longer dependent upon the Tabs component.
@paulrobertlloyd
Copy link
Contributor

I’d be up for making this an ‘officially unofficial’ component. We already use it in a few places (Prototype components, Accessibility mistakes) and can see it being useful as a component you might want to include in reference documentation.

And I agree, keeping the more opinionated bits out of the component makes sense. Let it do one thing well. No reason why those functions couldn’t be exports though, and able to be unofficially imported into other projects as Nunjucks globals.

docs/autocomplete.md Show resolved Hide resolved
</li>{%- endfor -%}
</ul>
</div>
{%- for codeSample in params.codeSamples -%}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be a little less specific; perhaps call a tab a tab? What do they use in the GOV.UK Design System docs?

Suggested change
{%- for codeSample in params.codeSamples -%}
{%- for tab in params.tabs -%}

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wasn't sure about this either.

The Design System website code has an example component and a custom Tabs component, with one nested inside the other. That felt a bit confusing to me, not to mention that 'tabs' is already a govuk component, but perhaps it’s ok.

Could go with 'items' which is the go-to when you're not quite sure what to call it? 😂

@@ -3,6 +3,10 @@
{% block scripts %}
<script src="/assets/iframeResizer.js"></script>
<script>
iFrameResize({}, `[data-module="app-example-frame"]`)
iFrameResize({}, `[data-module="x-govuk-example-frame"]`)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The requirement to add the iFrame script to both the source content and the page that consumes the component either needs incorporating into the component somehow, else documenting how to set up. Part of me wonders if their might be something cleaver we could do with web components, but that’d be very different to how other components work.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah this is super annoying. Seems odd that there’s no way to set an iframe to natively resize to its contents but I guess there were performance reasons why that wasn’t built in?

Could bundle the iframeresizer script with the xGovukExample component javascript itself, but that means an extra dependency and might be tricky? Possibly worth investigating still though. Otherwise we’d just have to document it well as something extra that you have to add to make dynamic iframe sizing work. Possibly there’s some contexts where a fixed height would be ok and you wouldn’t need it, but it does feel quite essential?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants