Allow individual components to be imported into apps

[andysellick]

What

Change the components gem to support the model proposed in RFC 108 where individual components are included in an application rather than all of them.

The Sass now contains two additional files necessary for applications when importing individual components:

• govuk_frontend_support, which contains general settings from the gem plus everything from govuk-frontend that adds no weight to the compiled CSS (settings, tools and helpers)
• component_support, which contains everything else from govuk-frontend, plus helpers and mixins from the gem used by various components

So an application would import both of these files, then the sass for the components it needs. This has been split into two files like this so that static can import the first one without incurring additional CSS size or duplication, while still being able to make use of govuk-frontend mixins and variables (we need this now we're removing toolkit from static).

The component guide's sass is separate and has been updated to include all components, since several are used.

The previous mechanism for including the gem's Sass is untouched, so this change should be backwards compatible.

Why

See the RFC.

Visual Changes

Visual changes to a component guide inside an application. Now generates a list of components at the top that are used by this application. Also added numbers to all of the headings.

Underneath this heading is a snippet of Sass that can be used in the app to replace the @import all_components line, again generated.

View Changes

https://govuk-publishing-compo-pr-1159.herokuapp.com/component-guide

Impact of the change

I've done some testing to see what impact these changes have on CSS files in applications. Here's some early results.

Application	application.css	print.css
finder-frontend	Before: 678 KB	Before: 36 KB
finder-frontend	After: 474 KB	After: 9 KB
government-frontend	Before: 692 KB	Before: 36 KB
government-frontend	After: 551 KB	After: 10 KB
collections	Before: 703 KB	Before: 35.6 KB
collections	After: 580 KB	After: 16.4 KB

We also want to check how long the Sass takes to compile compared to previously. Here are some numbers, but they seem to vary considerably between tests with the same app, so they may not be reliable.

These tests are done by:

• bundle exec rake assets:clean
• rm -rf public/NAME-OF-APP/*
• time bundle exec rake assets:precompile

Application	Current compile time	New compile time
government-frontend	1m57.699s	0m36.342s
finder-frontend	0m10.247s	0m10.957s
collections	1m3.144s	1m23.469s

The cookie banner question

The cookie banner is displayed from static. Currently, since every application pulls in every component, when a page is rendered the markup for the cookie banner comes from static but the styles come from the gem, via the app.

The new auto-generated list of sass files needed by an app therefore doesn't include the cookie banner, because the app doesn't use it. So I'm seeing the cookie banner unstyled when testing. There are two solutions:

• hard code the cookie banner sass into the suggested sass for every application
• import the cookie banner sass into static (this should be possible without extra imports, the sass seems to only depend on some govuk-frontend mixins, which static would have at that point)

Importing the cookie banner sass into static seems like the best option - it avoids duplication and puts the sass where it's actually used. This might need documenting somewhere when we change static to include these changes, I'm writing this to remind myself.

[kr8n3r]

in GOV.UK Frontend we built a mechanism in Sass that will only export components Sass once, no matter how many times it's imported - that's why aevery component's Sass in wrapped in an exports include

is there the same need in this implementation?

[andysellick]

@kr8n3r possibly, although I'm currently more concerned about importing too much of the rest of govuk-frontend than I am of duplicating sass imports for our components. Although at some point we definitely want to import all of it, since we'll use all of it in apps somewhere.

[kr8n3r]

@andysellick 👍
see if you can work with just importing

@import "settings/all";
@import "tools/all";
@import "helpers/all";

from govuk-frontend as these should not output any code

[andysellick]

Note to self: this change to the model may be beneficial for static, in that it might be possible to make govuk-frontend's mixins available to static via the 'component_support' sass file here, see alphagov/static#2023 for an example of duplication that this could remove.

[alex-ju]

I had a quick look at this in preparation for today's meeting. While I like the "suggested sass" feature, I'm not sure about the approach to split the helpers. In a world where static will be using the public-frontend layout I don't see a need for it to require any helpers.

[alex-ju]

Technically this looks ok and I understand this unblocks the ongoing work in static (by reducing unnecessary code duplication and enabling mixins usage from govuk-frontend). I do however expect govuk_frontend_support.scss and component_support.scss not to be separated for long as we're working to introduce the public frontend layout which means static shouldn't require any styles. Also, long-term, applications should ideally only require one file to pull in sass from govuk_publishing_components.