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

Proposal: Add modifiers to nunjucks templates #667

Closed
richardTowers opened this issue Apr 19, 2018 · 3 comments
Closed

Proposal: Add modifiers to nunjucks templates #667

richardTowers opened this issue Apr 19, 2018 · 3 comments

Comments

@richardTowers
Copy link
Contributor

At the moment if you want to turn a button into a start button you would use a nunjucks macro like this:

{{ govukButton({text: "Start now button", classes: "govuk-button--start"}) }}
<!-- Compiles to -->
<input value="Start now button" type="submit" class="govuk-button govuk-button--start">

The macro already knows it's a govuk-button element, so it feels redundant having to say it again in the classes. It also means the nunjucks macros don't protect the user from classname changes as well as they might.

What do you think about adding a modifiers field alongside classes which would automatically prepend the appropriate block / element bits of the classname to the output? So:

{{ govukButton({text: "Start now button", modifiers: "start"}) }}
<!-- Compiles to -->
<input value="Start now button" type="submit" class="govuk-button govuk-button--start">
@richardTowers richardTowers changed the title Proposal: Add modifiers to nunjucks templates Proposal: Add modifiers to nunjucks templates Apr 19, 2018
@kr8n3r
Copy link

kr8n3r commented Apr 20, 2018

Hi @richardTowers
thanks for raising this.

In the first iteration of the component macros we were using boolean values to represent variants (and output css classes).

In the base of the button, it can be a <button>, <a> or input type="submit". Users might be confused what a modifier does: is it a new class or different tag.

We're open to feedback from users and we'll evaluate this proposal to see if we can make it work for compound components as well, so that the approach is consistent.

@NickColley
Copy link
Contributor

NickColley commented Apr 20, 2018

I raised a similar issue related to breaking upgrades: #460

See also the GOV.UK Publishing component: http://govuk-static.herokuapp.com/component-guide/button/start_now_button

Link to code: https://github.com/alphagov/static/blob/a9a040a72d475ef7015c1c9e690a5d77687fcfd8/app/views/govuk_component/button.raw.html.erb#L1

We constructed the class based on booleans, then finally merge with classes and inject into the markup.

In terms of confusion, if they're documented properly, I've not seen any issue with flags.

@richardTowers
Copy link
Contributor Author

Ah, I hadn't seen #460, which looks similar enough that I think we should close this one as a dupe.

I'll add another comment to that with my opinions.

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

No branches or pull requests

3 participants