wexample / symfony-design-system
Design system assets for Symfony
Package info
github.com/wexample/symfony-design-system
Language:Twig
pkg:composer/wexample/symfony-design-system
Requires
- php: >=8.2
- wexample/symfony-loader: >=4.0.0
This package is auto-updated.
Last update: 2026-08-28 10:32:58 UTC
README
Version: 6.0.0
A Symfony bundle that ships a ready-made design system for web applications: Twig components (buttons, modals, toasts, forms, entity bars), SCSS layouts (dashboard and default), Vue mixins, and a suite of Twig extensions that wire them together. Every page flows through a RenderPass object managed by AbstractDesignSystemController, which handles template resolution, per-layout asset loading, and render-node–scoped translations. It targets Symfony developers who want consistent UI primitives and a structured front-end pipeline without building one from scratch.
Table of Contents
- Architecture
- Integration in the Suite
- Dependencies
- Versioning & Compatibility Policy
- License
- About us
- Migration Notes
Architecture
The bundle is a Symfony library (wexample/symfony-design-system) that adds a ready-made design system on top of wexample/symfony-loader. It ships PHP services (Twig extensions, controllers), layout templates, component triads (Twig + TypeScript + SCSS), and shared CSS and Vue primitives. Nothing here is an application; every piece is meant to be extended or overridden by the host app.
Bundle registration and service wiring
src/WexampleSymfonyDesignSystemBundle.php extends AbstractBundle and implements LoaderBundleInterface. Its only runtime responsibility is to tell the loader where the bundle's front-end assets live:
public static function getLoaderFrontPaths(): array { return [ BundleHelper::getBundleCssAlias(static::class) => __DIR__ . '/../assets/', ]; }
src/DependencyInjection/WexampleSymfonyDesignSystemExtension.php calls loadConfig() (which reads src/Resources/config/services.yaml) and then merges two layout bases — modal and panel — into the loader's parameter wexample_symfony_loader.layout_bases. That parameter tells the loader which component to use as the container when a page is embedded inside an overlay.
services.yaml registers every class under Controller\, Form\, Service\, and Twig\ with autowiring and autoconfigure. AppExtension is excluded from the wildcard scan and registered separately so its $appHomeRoute constructor argument can be injected from the wexample_ds_app_home_route parameter.
Twig layer
All Twig extensions extend src/Twig/AbstractTemplateExtension.php, which wraps twig->render() in renderTemplate() and declares TEMPLATE_FUNCTION_OPTIONS (is_safe: html, needs_environment: true). Each extension owns one visual concern:
| Extension | Functions registered |
|---|---|
| src/Twig/AppExtension.php | app_home_url() — resolves wexample_ds_app_home_route, returns # when absent or unroutable |
| src/Twig/BreadcrumbExtension.php | breadcrumb(), breadcrumb_render(), breadcrumb_append_route(), breadcrumb_stack() — trail is accumulated in Request::attributes under _breadcrumb_stack |
| src/Twig/ButtonExtension.php | button(), button_menu(), button_link(), button_modal(), button_panel() — delegate to the loader's ComponentsExtension::component() |
| src/Twig/EntityExtension.php | entity($renderPass, $entity, $format) — resolves @front/components/entity/{snake_name}/{format} via ComponentsExtension |
| src/Twig/FormExtension.php | form_submit() — renders partials/button.html.twig with type: submit injected |
| src/Twig/ImageExtension.php | content_image() — renders partials/content-image.html.twig with loading: lazy as default |
| src/Twig/MenuExtension.php | menu_item(), menu_separator(), menu_item_link(), menu_item_collapsible(), menu_item_collapsible_from_controller() |
| src/Twig/MessageExtension.php | message_info(), message_success(), message_warning(), message_error() — all render partials/message.html.twig with a type and a default icon |
| src/Twig/TabExtension.php | tab_item(), tab_item_link() — render partials/tab-item.html.twig |
| src/Twig/UiStateExtension.php | ui_state_get($key, $default) — reads from session['ui_state.{key}'] |
button_modal() and button_panel() compute the target URL with UrlGeneratorInterface, merge it into $options, and then call renderOverlayButton(), which delegates to ComponentsExtension. The component name maps to @WexampleSymfonyDesignSystemBundle/components/button-modal or button-panel.
menu_item_collapsible_from_controller() builds the submenu automatically: it scans RouterInterface::getRouteCollection() for routes whose _controller class path shares a namespace prefix with the given controller namespace, keeps only the top-level or index routes (using ClassHelper), then compares each against the current request route to decide whether the group is open.
Controllers
src/Controller/UiStateController.php exposes POST /ui-state/set. It reads {key, value} from the JSON body and writes session['ui_state.{key}'] = value. This is the default persistence target for menu-collapse state; apps that need server-side persistence override App::persistUiState on the JS side instead of calling this endpoint.
src/Controller/FixturesController.php serves placeholder.svg from assets/fixtures/ at the design-system base route.
src/Traits/SymfonyDesignSystemBundleClassTrait.php returns WexampleSymfonyDesignSystemBundle::class as the bundle class name. A controller mixing it in tells the loader which bundle to resolve template namespaces and translation paths against; the preview controllers that do so live in the symfony-design-system-demo package, not here.
Helper
src/Helper/EntityDisplay.php is a value-object holding the three standard entity display identifiers (bar, card, list-item) that the entity() Twig function uses to resolve component paths. Custom formats beyond these are valid; the class documents the standard set rather than enforcing it.
Asset layout
Assets live in assets/ and are divided into five directories.
layouts/ defines the two provided HTML layouts. assets/layouts/default/layout.html.twig extends the loader's base layout and adds the page_body_container block (wraps the body in a container with an optional h1). assets/layouts/dashboard/layout.html.twig extends default and renders a two-sidebar shell: a left menu-collapsible-panel, a scrollable main content column, and a right menu-collapsible-panel. The left panel reads its initial collapsed state from ui_state_get('ui.layout.menu.left', true). Host apps extend dashboard/layout.html.twig to inject page_menu_links and other blocks.
components/ holds interactive units. Each component is a triad: a .html.twig template rendered server-side, a .ts file that attaches client behaviour, and a .scss file for component-scoped styles. Notable components:
modalandpanelboth extendAbstractOverlayPageManager(assets/js/Class/AbstractOverlayPageManager.ts), which layersFadeAnimationMixin,FocusableComponentMixin, andOverlayMixinfrom the loader. It handles open/close with optional confirm-on-close and dirty-form detection.button-modal(assets/components/button-modal.ts) andbutton-panel(assets/components/button-panel.ts) extendAbstractOverlayButton(assets/js/Class/AbstractOverlayButton.ts), which intercepts clicks, reads options from adata-*attribute, and calls intoModalServiceorPanelServicefrom the loader. Both use URL hash params to restore persistent overlays on page reload.menu-collapsible-panel(assets/components/menu-collapsible-panel.ts) togglesgutters--collapsible--collapsedon its element and callsapp.onMenuStateChange(menuId, open)on every toggle, which is the point where the host app or the defaultUiStateControllerpersist the state to the session.toastappliesFadeAnimationMixin,AutoCloseMixin, andActionLinksMixin; it self-removes after 4 s unlessstickyis set.
js/ contains shared TypeScript classes and Vue mixins.
AbstractCollapsibleComponent(assets/js/Class/AbstractCollapsibleComponent.ts) listens for a click on a selector returned bygetToggleSelector()and togglesis-openon the element.AbstractDesignSystemVueMixin(assets/js/Vue/AbstractDesignSystemVueMixin.ts) addswaitForAppReady()to any Vue component that must wait for the JS app to finish bootstrapping before performing async work.
vue/ holds Vue 3 single-file components and their .vue.twig server-side wrappers. bases/entity.vue and bases/form.vue are the root Vue components for entity and form contexts; field components under vue/form/fields/ map one-to-one to the Symfony form types declared in src/Form/Demo/.
css/ is organised into: mixins/ (SCSS mixins for layout, spacing, typography, overlays), shapes/ (one file per UI shape such as _button.scss, _modal.scss, _menu.scss), partials/ (palette, global variables, colour-scheme overrides), utilities/ (alignment, text-align, visually-hidden), and primitives/ (feedback). The palette file assets/css/partials/_palette.scss declares colour variables with !default so host apps can override them by importing their own palette first.
Call path through the stack
A typical page request arrives at a controller that calls renderPage('index'). The loader's AbstractPagesController builds a RenderPass (tracking the bundle, view name, and layout bases), passes it through adaptiveRender(), and ultimately calls twig->render(). The template extends dashboard/layout.html.twig → default/layout.html.twig → the loader's HTML base, which owns the <!DOCTYPE html> shell.
Inside a template, calling {{ button_modal(...) }} invokes ButtonExtension, which generates the URL and calls the loader's ComponentsExtension::component(). That function renders components/button-modal.html.twig server-side and registers the component with the render pass so the loader emits the correct JS bootstrap data. When the browser executes that bootstrap data, button-modal.ts mounts, listens for clicks, and delegates to ModalService, which fetches the target page and hands it to modal.ts — an AbstractOverlayPageManager — to display.
UI state flows in the reverse direction: menu-collapsible-panel.ts fires app.onMenuStateChange(id, open) → App::persistUiState POSTs to /ui-state/set → UiStateController writes to the session → on the next page load ui_state_get('ui.layout.menu.left') returns the saved value and dashboard/layout.html.twig renders the panel pre-collapsed or pre-open.
Integration in the Suite
This package is part of the Wexample Suite — a collection of high-quality, modular tools designed to work seamlessly together across multiple languages and environments.
Related Packages
The suite includes packages for configuration management, file handling, prompts, and more. Each package can be used independently or as part of the integrated suite.
Visit the Wexample Suite documentation for the complete package ecosystem.
Dependencies
- php: >=8.2
- wexample/symfony-loader: >=4.0.0
Versioning & Compatibility Policy
Wexample packages follow Semantic Versioning (SemVer):
- MAJOR: Breaking changes
- MINOR: New features, backward compatible
- PATCH: Bug fixes, backward compatible
We maintain backward compatibility within major versions and provide clear migration guides for breaking changes.
License
This project is licensed under the MIT License - see the LICENSE file for details.
Free to use in both personal and commercial projects.
About us
Wexample stands as a cornerstone of the digital ecosystem — a collective of seasoned engineers, researchers, and creators driven by a relentless pursuit of technological excellence. More than a media platform, it has grown into a vibrant community where innovation meets craftsmanship, and where every line of code reflects a commitment to clarity, durability, and shared intelligence.
This packages suite embodies this spirit. Trusted by professionals and enthusiasts alike, it delivers a consistent, high-quality foundation for modern development — open, elegant, and battle-tested. Its reputation is built on years of collaboration, refinement, and rigorous attention to detail, making it a natural choice for those who demand both robustness and beauty in their tools.
Wexample cultivates a culture of mastery. Each package, each contribution carries the mark of a community that values precision, ethics, and innovation — a community proud to shape the future of digital craftsmanship.
Migration Notes
When upgrading between major versions, refer to the migration guides in the documentation.
Breaking changes are clearly documented with upgrade paths and examples.