Download the PHP package wexample/symfony-design-system without Composer

symfony_design_system

Version: 11.0.2

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:

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:

button_target($icon, $label, $href, $target, $options) takes the same first three arguments as button_link(), plus where the page it points at is loaded: modal, panel, or the name of an embed the page holds. It merges href and target into $options and renders components/button-target. The class list is the caller's — options.class replaces it entirely, defaulting to button — because the same behaviour has to sit on a .button and on a .table--icon-link.

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.

Double rendering

An element of the design system is rendered on the server by Twig, or in the browser by Vue, and the choice belongs to the page, not to the element. So an element that a Vue-rendered page may need exists twice: a Twig triad and a Vue twin, emitting the same markup and taking the same options.

This is not duplication for its own sake. A Twig component binds its behaviour through the loader's .com-init placeholder, which resolves the element from the previous DOM node — a mechanism that cannot reach markup Vue produced. A table drawn by data-table.vue therefore cannot host components/button-target.html.twig, however much both would like it to.

The rule that keeps the pair honest:

• Twin files say so, at the top, both ways: "Client-side twin of X: same options, same markup. A change to either is a change to both."
• The markup is identical, class for class. Where Vue needs an extra element for v-html or a v-if, the twin is restructured until the output matches.
• The behaviour is shared by a module both import — assets/js/Helper/TargetHelper.ts for the target buttons — so a rule about what happens lives in one place even when what is drawn lives in two.
• Options carry the same names on both sides. Where the language forces a difference, it is the mechanical one only: class becomes className, snake_case Twig option keys become camelCase Vue props.

The principle is being deployed progressively; the elements that already have their twin:

Tables: where the twins part company

The table pair is the oldest and the one with the most divergence. It is unavoidable, and worth knowing before trying to unify them:

• The Vue side accepts functions for format, href, icon and params, and resolves routes through the routing service. Twig has no closures and the URLs are already known at render time, so the Twig side takes the computed result in the row: a link cell reads { label, href }, an icon cell { icon, href }, an actions cell a list of { icon, href }.
• secondary is applied to header and body cells by the Vue component, to body cells only by the partial.
• The Vue component has a refreshing state — rows dimmed under an overlay while new ones load — which a server-rendered table cannot have. The Twig loading option only replaces the body with the spinner row.

Shared column options: key, label, align, secondary, class (className in Vue), and cell for the cell kind — text, html, icon, link, actions. An actions cell entry may carry target and target_options (targetOptions in Vue), which both sides hand to the target button.

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:

• modal and panel both extend AbstractOverlayPageManager (assets/js/Class/AbstractOverlayPageManager.ts), which layers FadeAnimationMixin, FocusableComponentMixin, and OverlayMixin from the loader. It handles open/close with optional confirm-on-close and dirty-form detection.
• button-target (assets/components/button-target.ts) intercepts clicks on its anchor, reads data-target and data-target-options, and hands the href to loadIntoTarget() from assets/js/Helper/TargetHelper.ts, which dispatches to ModalService, PanelService or EmbedService. The two overlays keep their place in URL hash params, so a persistent one reopens on reload; an embed does not, belonging to the page that placed it. A modified click is left to the browser, so every target stays openable as a full page.
• menu-collapsible-panel (assets/components/menu-collapsible-panel.ts) toggles gutters--collapsible--collapsed on its element and calls app.onMenuStateChange(menuId, open) on every toggle, which is the point where the host app or the default UiStateController persist the state to the session.
• toast applies FadeAnimationMixin, AutoCloseMixin, and ActionLinksMixin; it self-removes after 4 s unless sticky is set.

js/ contains shared TypeScript classes and Vue mixins.

• AbstractCollapsibleComponent (assets/js/Class/AbstractCollapsibleComponent.ts) listens for a click on a selector returned by getToggleSelector() and toggles is-open on the element.
• AbstractDesignSystemVueMixin (assets/js/Vue/AbstractDesignSystemVueMixin.ts) adds waitForAppReady() 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_target(..., 'modal') }} invokes ButtonExtension, which calls the loader's ComponentsExtension::component(). That function renders components/button-target.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-target.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.5
• wexample/symfony-live: >=4.0.0
• wexample/symfony-loader: >=6.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.