Les constructeurs de plugins WordPress ne devraient pas définir de crochets

Les constructeurs de plugins WordPress semblent être de plus en plus un sujet de débat quand il s’agit de ce qu’ils devraient définir. J’en ai déjà parlé, mais il est normal de revenir sur un sujet comme celui-ci de temps en temps, n’est-ce pas ?

Après tout, il y a des choses que nous apprenons et des choses que nous changeons à mesure que nous acquérons plus d’expérience.

Il n’est pas du tout rare de voir des plugins définir des hooks et d’autres comportements, mais je ne suis pas fan de cette approche. Au lieu de cela, je pense que la gestion de l’enregistrement des crochets devrait être effectuée dans sa propre fonction ou, encore plus radicalement, gérée par un ensemble de classes.

Mais avant d’entrer dans les détails, je veux expliquer ce qui devrait aller dans un constructeur de plugin WordPress, pourquoi il devrait aller dans un constructeur et comment cela peut être géré lorsque vous travaillez sur vos plugins.

Constructeurs de plugins WordPress

Dès le départ, je pense que les constructeurs doivent être utilisés pour une chose :

• Initialisation de l’état d’un objet.

Ce qui définit l’état initial d’un objet peut dépendre du fait qu’il a été créé "à partir de zéro" ou s’il est chargé avec des informations d’un ensemble précédent (comme une session en cours de sérialisation). La façon dont je le vois :

• les attributs sont des noms qui décrivent un objet,
• les fonctions sont des verbes qui décrivent ce que l’objet peut faire.

Les fonctions, bien sûr, font le travail que l’objet est capable de faire. Ils peuvent modifier l’état de l’objet lorsqu’il est appelé, ou ils peuvent travailler sur les arguments passés aux fonctions.

Que doit-on mettre dans un constructeur ?

Lorsqu’un objet est construit, il doit simplement être défini de manière à ce que ses attributs soient définis et que ses fonctions soient prêtes à fonctionner.

S’il y a quelque chose dans le constructeur qui n’a pas d’impact sur l’état initial d’un objet, il ne devrait pas s’y trouver.

Pourquoi les attributs devraient-ils être dans un constructeur ?

Peut-être une meilleure façon de poser cette question est:

Pourquoi les crochets ne devraient-ils pas être définis dans le constructeur ?

Le système de hook de WordPress fait partie du modèle de conception piloté par les événements (dont je suis fan), mais l’enregistrement des hooks ne décrit pas l’état de l’objet. Au lieu de cela, au niveau le plus fondamental, c’est quelque chose qui crée une relation avec l’objet et WordPress.

L’état initial de l’objet n’a pas besoin de connaître WordPress, d’avoir l’une de ses fonctions configurées pour être couplée à WordPress ou d’effectuer un traitement avec WordPress.

N’oubliez pas que les attributs sont initialisés dans un constructeur. WordPress n’est pas un attribut. C’est une dépendance. Créer une dépendance, c’est effectuer une action qui est la définition d’un verbe.

Ainsi, tous les enregistrements de hook doivent être effectués dans une fonction.

Comment pouvons-nous gérer l’enregistrement des crochets ?

C’est l’un de ces sujets qui peuvent être un article ou une série d’articles à part entière.

• Il est possible de créer une classe qui maintient un registre d’objets et les crochets avec WordPress.
• Il est également possible de définir l’enregistrement du hook dans une fonction de la classe.
• Nous pouvons également faire un certain nombre de choses avec l’inversion de dépendance.

Tout ce qui précède dépasse le cadre de cet article, mais par souci de simplicité, je vais montrer un exemple de la façon dont une classe peut enregistrer ses fonctions avec WordPress dans une fonction init :

<?php

namespace AcmeAdmin;
use AcmeAdminInterfaces;

class JavaScript_Assets implements InterfacesAsset {

    private $assets_dir;

    private $js_dir;

    public function __construct() {

        $this->assets_dir = trailingslashit(
            plugin_dir_url( __FILE__ ). 'assets'
        );

        $this->js_dir = trailingslashit( $this->assets_dir. 'js' );
    }

    public function init() {

        add_action(
            'admin_enqueue_scripts',
            array( $this, 'enqueue') );
    }

    public function enqueue() {

        wp_enqueue_script(
            'toggle-admin-notices',
            $this->js_dir. 'admin.js',
            array( 'jquery' ),
            false
        );
    }
}

De cette façon, nous pouvons instancier l’objet, le tester, l’utiliser, etc., mais nous n’avons pas à nous occuper de tout ce qui concerne WordPress sans appeler explicitement la  fonction init.

Une fois que cela est appelé, la dépendance est créée, WordPress est nécessaire et les choses se compliquent.

Oh, et cette chose de test

Je veux mentionner un autre point qui dépasse un peu la portée et le but de cet article mais qui est toujours pertinent : lorsqu’il s’agit de tester une classe, nous devrions être en mesure de :

1. créer une instance de la classe,
2. tester sa logique en appelant des fonctions,
3. en lui passant des paramètres et en évaluant ses valeurs de retour.

Et nous devrions être capables de faire autant de choses que possible de manière isolée. Si des crochets sont définis dans le constructeur, cela crée une dépendance immédiate à WordPress qui ne devrait pas être nécessaire.

WordPress ne décrit pas l’état d’un objet. C’est une dépendance de l’objet.

Quoi qu’il en soit, le point que j’essaie de faire valoir est que les constructeurs de plugins WordPress ne doivent pas gérer l’enregistrement des crochets car les crochets ne décrivent pas son état. Ils sont liés à quelque chose que fait la classe et nous empêchent de tester un objet isolément.

Ils ont donc leur place, mais ce n’est pas dans le constructeur.