WordPress : Mon approche des styles de mise en file d’attente est-elle inefficace ?

Je suis un peu novice en wordpress et en programmation en général. J’ai la question suivante.

Récemment, je suis tombé sur cet article et j’ai voulu utiliser cette approche dans le thème wordpress sur lequel je travaille.

J’ai écrit cette classe Enqueue pour mettre en file d’attente mes styles et js dans le thème:

<?php

class Enqueue
{

   private function actionEnqueueScripts($function) {
        add_action('wp_enqueue_scripts', function () use ($function) {
            $function();
        });
    }


   public function addStyle($handle, $src = '', $deps = array(), $ver = false, $media = 'all') {
        $this->actionEnqueueScripts(function () use ($handle, $src, $deps, $ver, $media) {
            wp_enqueue_style($handle, $src, $deps, $ver, $media);
        });
        return $this;
    }

}

Pour cela, je peux ajouter des styles dans mon function.php comme ceci :

require_once 'vendor/class-enqueue.php';

$theme = new Enqueue;

$theme->addStyle('stylesheet-1', get_template_directory_uri() . '/dist/assets/css/bundle.css', array(), time(), 'all')
      ->addStyle('stylesheet-2', get_template_directory_uri() . '/dist/assets/css/bundle.css', array(), time(), 'all');

Ma question est : n’est-ce pas un peu inefficace ? Parce que, chaque fois que j’ajoute un fichier css, n’appelle-t-il pas le hook add_action ‘wp_enqueue_scripts ? alors que dans une approche procédurale j’appellerais cette action hook une seule fois pour tous les styles ? ça va?

PS : si tout va bien, serait-il possible d’ajouter des conditions à la méthode addStyle ? comme ça

$theme->(if(is_single)) addStyle('stylesheet-1', get_template_directory_uri() . '/dist/assets/css/bundle.css', array(), time(), 'all')

Merci pour la lecture.

Solution n°1 trouvée

(note latérale). Les classes d’écriture ne signifient pas que votre code est OOP. Beaucoup de gens confondent l’utilisation des classes avec la POO alors que les classes ne sont qu’une syntaxe qui vous permet de regrouper des méthodes et des données. Pour la POO, vous devez en fait déterminer quels sont les objets de votre système et quelles opérations peuvent être effectuées sur eux.

Une mauvaise POO peut en fait conduire à un code trompeur. Par exemple cette ligne de ce poste

$theme->addSupport('post-thumbnails');

mais en pratique ce n’est pas le thème auquel on rajoute un support des post thumbnails mais en fait l’admin wordpress donc cela aurait été un code plus précis

$wp->addThemeSupport($theme, 'post-thumbnails');

En éliminant les ordures théoriques, nous pouvons nous concentrer sur la question actuelle 😉

1. Oui, comme dans toutes les autres mauvaises implémentations de POO, vous obtenez un code très verbeux sans réel avantage, mais… c’est juste un style de codage, et si ce genre de « tout emballer avec des classes » vous rend plus productif, vous devriez opter pour mais il n’y a rien d’intrinsèquement meilleur dans la POO par rapport au code procédural et fonctionnel.

2. Du point de vue de l’efficacité, le nombre de fois que vous ajoutez une action n’a pas vraiment d’importance, car la surcharge est minime par rapport aux goulots d’étranglement qui sont généralement liés à l’accès à la base de données. Votre capacité à lire et à maintenir le code dans le temps est x100 plus importante qu’une micro-optimisation.