Static Container Twig Extension Bundle Laravel Package

Product Decisions This Supports

• Decoupling Frontend Logic from Backend Services: Enable reusable, template-level data sharing without requiring backend API calls or complex state management. Ideal for multi-template applications (e.g., microservices, headless CMS, or modular frontend architectures).

• Build vs. Buy: Buy for teams needing lightweight, zero-configuration template data sharing. Avoid reinventing a Twig extension for static data propagation. Build only if requiring advanced features like runtime validation or dynamic key scoping.

• Roadmap for Templating Overhauls: Adopt as a stepping stone for migrating legacy Twig templates to a more modular structure. Useful for:

  • Progressive decoupling of frontend components.
  • A/B testing variants (e.g., sharing global configs like {{ static_ab_test_variant }} across templates).
  • Localization/regionalization (e.g., {{ static_currency_symbol }}).

• Use Cases:

  • Monolithic Symfony Apps: Share static configs (e.g., API endpoints, feature flags) across templates without polluting controllers.
  • Static Site Generators: Pre-populate Twig templates with metadata (e.g., SEO tags, social media cards) during build time.
  • Multi-Tenant Apps: Isolate tenant-specific static data (e.g., branding colors) per template render.

When to Consider This Package

• Adopt When:

  • Your app uses Symfony 8.0+ and Twig for templating.
  • You need to share immutable data (e.g., configs, constants) across templates without backend roundtrips.
  • Development velocity is prioritized over runtime flexibility (e.g., no need for dynamic key invalidation).
  • You’re avoiding global variables or service containers for template data (cleaner separation of concerns).

• Look Elsewhere If:

  • You require runtime data modification (e.g., user-specific overrides). Use Symfony’s ContainerInterface or a dedicated cache layer instead.
  • Your templates need complex data structures (e.g., nested objects). Consider Twig’s built-in {% set %} or a custom Twig filter.
  • You’re on PHP < 8.5 or Symfony < 8.0. This package lacks backward compatibility.
  • Security is a concern: Static keys are not sanitized by default (validate inputs if using user-provided keys).
  • You need performance-critical shared data (this adds minimal overhead, but not optimized for high-frequency template renders).

How to Pitch It (Stakeholders)

For Executives:

"This package lets us eliminate redundant backend calls for static template data—like configs, feature flags, or SEO metadata—by sharing it directly between Twig templates. For example, instead of fetching the same API endpoint in every controller for a global header, we define it once in a template and reuse it everywhere. This reduces server load, speeds up page renders, and simplifies maintenance. It’s a zero-cost upgrade for Symfony/Twig apps, with MIT licensing and active (if niche) development. Ideal for projects prioritizing frontend modularity or migrating to headless architectures."

For Engineering:

*"Problem: Sharing static data across Twig templates currently requires either:

• Polluting controllers with template-specific logic, or
• Building a custom solution (e.g., Twig globals or services).

Solution: This bundle provides a dedicated static_* namespace in Twig to store key-value pairs globally. Key benefits:

• No backend changes: Works purely in the templating layer.
• Lightweight: ~50 lines of code, zero dependencies beyond Symfony/Twig.
• Flexible: Supports any data type (strings, arrays, objects) as long as it’s serializable.
• Future-proof: Aligns with Symfony’s component-based architecture.

Trade-offs:

• Not for dynamic data (use services/containers instead).
• Requires discipline to avoid overusing it (e.g., don’t store user-specific data here).

Proposal: Pilot this in our [Project X] templates to replace hardcoded configs. If successful, roll out to other Twig-heavy modules. Effort: 1 hour to install + template updates. ROI: Faster renders, cleaner code."*