mediagone/twig-powerpack

Provides code-quality helpers to your Twig templates.

0.2.5 2021-04-11 10:44 UTC

This package is auto-updated.

Last update: 2024-12-11 19:20:25 UTC


README

⚠️ This project is in experimental phase.

Latest Version on Packagist Total Downloads Software License

This package provides code-quality features to your Twig templates:

  1. Type-safety checks for template context variables.
  2. Register global data/resources from any template.
  3. Instantiate classes in templates.

Along with new functionalities:

  • |json_decode filter

Installation

This package requires PHP 7.4+ and Twig 2+.

Add it as Composer dependency:

$ composer require mediagone/twig-powerpack

If you're using Symfony, enable the extension in services.yaml:

services:
    
    Mediagone\Twig\PowerPack\TwigPowerPackExtension:
        tags: [twig.extension]

Introduction

Twig templating engine is seriously lacking types....

Features

1) Context Variables type-checking

Templates usually require specific external data, but there is no native way to check the type of supplied variables. The expect tag allows you to declare required variables in your Twig files, making them also self-documenting. If the data is invalid, an exception will be thrown.

Primitive types

Supported scalar types are: bool, float, int and string.

{% extends 'layout.twig' %}

{% expect 'string' as TITLE %}
{% expect 'bool' as ENABLED %}
{% expect 'float' as AMOUNT %}
{% expect 'int' as COUNT %}

Note: TITLE, ENABLED, AMOUNT and COUNT represent the names of required variables.

Objects

Because they don't guarantee any data structure, anonymous objects (stdClass) are not supported. However, usage of named classes is strongly encouraged to expose data in your templates. Therefore, a Fully Qualified Class Name (FQCN) can also be supplied:

{% expect 'App\\UI\\ViewModels\\Foo' as FOO %}

{{ FOO.bar }}

Nullable

Sometimes, you may want to ensure that a variable is defined while making it optional by using the nullable keyword:

{% expect nullable 'App\\UI\\ViewModels\\Foo' as FOO %}

{% if FOO != null %}
...
{% endif %}

Arrays

You can also check if a variable is an array of a given type by using the array of keywords:

{% expect array of 'App\\UI\\ViewModels\\Foo' as ARRAY %}

{% for foo in ARRAY %}
...
{% endfor %}

Arrays can also be nullable:

{% expect nullable array of 'App\\UI\\ViewModels\\Foo' as ARRAY %}

{% if ARRAY != null %}
...
{% endif %}

Or contain nullable elements:

{% expect array of nullable 'App\\UI\\ViewModels\\Foo' as ARRAY %}

{% for foo in ARRAY %}
    {% if foo != null %}
    ...
    {% endif %}
{% endfor %}

And even nullable array of nullable elements!

{% expect nullable array of nullable 'App\\UI\\ViewModels\\Foo' as ARRAY %}

Note: Checking array's items type might induce a slight overhead, but unless you have thousands of elements it should be negligible.

2) Register global data from any template

You may occasionally declare specific data in your templates, used in the global scope. For example if your templates dynamically add CSS classes to HTML body, or if they require optional CSS or JavaScript resources you only want to include on demand.

String Data

Short string data can be registered from anywhere in your templates using the {% register <data> in <registry> %} tag:

// Page.twig

{% extends 'Layout.twig' %}

{% register 'has-menu' in 'bodyClasses' %}
{% register 'responsive' in 'bodyClasses' %}

{% register '/css/few-styles.css' in 'styles' %}
{% register '/css/some-styles.css' in 'styles' %}

{% register '/js/custom-scripts.js' in 'scripts' %}

...

And retrieved elsewhere through the registry() function:

// Layout.twig

<html>
    <head>
        ...
        
        {% for css in registry('styles') %}
        <link rel="stylesheet" href="{{ css }}" />
        {% endfor %}
        <!-- <link rel="stylesheet" href="/css/few-styles.css" /> -->
        <!-- <link rel="stylesheet" href="/css/some-styles.css" /> -->
    </head>
    <body class="{{ registry('bodyClasses')|join(' ') }}">
    <!-- <body class="has-menu responsive"> -->
        ...
        
        {% for js in registry('scripts') %}
        <script src="{{ js }}"></script>
        {% endfor %}
        <!-- <script src="/js/custom-scripts.js"></script> -->
    </body>
</html>

Optional registry clause

For convenience, the registry name can be automatically inferred from the data when it represents a path with an extension, making usage of in <registry> optional. The following lines are equivalent:

{% register '/styles.css' in 'css' %}
{% register '/styles.css' %}

Body Data

Because you may need longer or dynamically generated data, the tag also supports a block syntax to allow a content body to be provided. In this case you cannot define data in the opening tag and the registry clause is mandatory: {% register in <registry> %} <body data> {% endregister %}

For example if you want to declare inline scripts from a template:

// Page.twig
{% extends 'Layout.twig' %}

{% set name = 'world' %}

{% register in 'inlineJs' %}
    alert('Hello {{ name }}');
{% endregister %}

And include it at the end of the html page:

// Layout.twig

<html>
    <body>
        ...
    
        <script>
        {% for js in registry('inlineJs') %}
            {{ js|raw }}
        {% endfor %}
        <!-- alert('Hello world'); -->
        </script>
    </body>
</html>

Unicity

Data can be declared as unique, so if multiple templates register the same value, it will be included only once. It's required most of the time, just add the once keyword to the tag:

{% register once '/styles.css' %} 

// Subsequent identical statements will be ignored
{% register once '/styles.css' %}

It also works with body data:

{% register once '/styles.css' %}
{% register once in 'css' %}/styles.css{% register %}  // ignored

However, unicity is only enforced within the same registry, so both following statements will be taken into account:

{% register once '/styles.css' in 'css' %}
{% register once '/styles.css' in 'styles' %}

Priority

As you cannot always predict in which order data will be registered, you'll sometime need to ensure a data comes first, for example in the case of a script library required by others. Then, add the priority keyword at the end of your tag followed by a priority number (lower values come first*).

Tags without priority always come after prioritized ones.

Note: the order of data with the same priority (or undefined) is not guaranteed.

{% register '/last.js' %}
{% register '/second.js' priority 2 %}
{% register '/first.js' priority 1 %}

<!-- <script src="/first.js"></script> -->
<!-- <script src="/second.js"></script> -->
<!-- <script src="/last.js"></script> -->

3) Instantiate classes in templates

Although it's better to do it in the controller when possible, you may need to create class instances directly in a template. The new(string $fqcn, ...$args) function allows you to call the constructor of a given class:

{% include('Partials/Menu.twig') with {Menu: new('App\\UI\\Partials\\Menu',
    'Main menu',
    [
        {Label: 'Item 1', Href: '/url/to/item1'},
        {Label: 'Item 2', Href: '/url/to/item2'},
    ],
)} %}

Given the following View Model class:

namespace App\UI\Partials;

final class Menu
{
    private string $name;
    private array $items;
    
    public function __construct(string $name, array $items)
    {
        $this->name = $name;
        $this->items = array_map(static fn($item) => new MenuItem($item), $items);
    }
}

License

Twig PowerPack is licensed under MIT license. See LICENSE file.