Pages are rendered using components. Components in static are available to all applications through slimmer.
They are documented in the static component guide. When running static locally the component guide is available at: http://static.dev.gov.uk/component-guide.
Components follow rules set out by the govuk_publishing_components gem.
A component must:
The govuk_publishing_components gem provides a generator to stub the files you’ll need in each component:
bundle exec rails generate govuk_publishing_components:component [component_name]
There are currently two namespaces being used by static components: govuk- and pub-c-. This is due to a gradual move to following the component conventions outlined by the govuk_publishing_components_gem.
The old govuk- namespace is deprecated and no longer recommended.
When building new components in static, it is strongly recommended that you follow the pub-c- namespace. This indicates to other developers that the component lives within static and is used among multiple apps. For an example component, see the title component
Static components differ from application components. The component files are centrally hosted on static and exposed to applications via alphagov/slimmer. The partial is exposed over the network, and the CSS/JS are included by the shared templated layout.
One of the goals of components is to have consistency between the many different frontend applications. Components that are needed by different applications live in a central place (the static application) and are distributed to the different frontends over the network. This is done via Slimmer, in a similar way to layout templates.
This allows a component to be changed and deployed within static and each frontend application will automatically fetch a new version of the component template code.
The automatic updating allows changes to be made to every GOV.UK frontend app, without having to manually update and deploy them. With 15+ frontend apps, this makes updating components much easier.
However, this approach does have some costs. It's less explicit, and not as clear how the common component code is included or updated. Changes to the component interface/parameters require forwards-only migrations, which for components, would look like this:
- Release a version of static that introduces backwards compatible change to a component
- Migrate all frontends to use new API and stop depending on old one
- Release version of static to remove old implementation for a component