Uso de un registro, suscriptores y servicios en WordPress

TL; DR: Encuentro que el uso de un registro, suscriptores y servicios es muy útil al crear complementos y utilidades centrados en el back-end para WordPress. Esta publicación explica cómo hacerlo.

Después de trabajar con patrones de diseño, programación orientada a objetos y WordPress durante años, es probable que surjan formas comunes de resolver problemas.

Así es como obtuvimos patrones de diseño orientados a objetos para empezar, así que tal vez esta sea una variación centrada en WordPress de eso.

Aunque he escrito sobre cosas como los registros en artículos anteriores (y algunos que ni siquiera son tan antiguos ), nunca es una mala idea volver a visitar el mismo tema, especialmente cuando hay algo que seguir agregando a la toma anterior.

Un Registro, Suscriptores y Servicios

Todo lo que se describe a continuación debe entenderse dentro del contexto del complemento de WordPress. Es decir, esto no está destinado a ser leído como una forma de trabajar con otros marcos, lenguajes, aplicaciones o cuando se usa con otros patrones.

Recuerda eso al leer esto.

De todos modos, la idea general detrás de la combinación de estos tipos de objetos es la siguiente:

1. El registro maneja todos los suscriptores,
2. Los suscriptores escuchan ganchos dentro de WordPress (los que existen o incluso ganchos personalizados),
3. Los servicios hacen el trabajo real cada vez que el suscriptor los envía.

El objetivo es que haya un lugar único para registrar las clases responsables de enviar el trabajo. Eso es todo.

Además, esto también facilita mantener las cosas separadas, de modo que si desea probar sus servicios de forma aislada, es mucho más fácil porque no están necesariamente acoplados estrechamente a WordPress. Y si lo son, puede simular los datos que deben pasarse a una función determinada y luego evaluar el resultado.

Sin embargo, este no es un artículo sobre pruebas, así que volvamos a las clases reales.

Registro

Por definición, el propósito de un registro es hacer un seguimiento de las cosas. Cuando se trata de implementar este patrón en WordPress, la idea es que el registro pueda realizar un seguimiento de los suscriptores (que definiré más adelante en este artículo).

Foto de Denny Müller en Unsplash

Además, la idea es que cuando llegue el momento, que probablemente será diferente según la estructura de su complemento, todos los suscriptores serán instanciados. Sin embargo, hasta ese punto, es probable que desee hacerlo al principio del ciclo de vida de WordPress.

Dicho esto, aquí tienes un ejemplo de cómo hacer el código para dar de alta a los suscriptores:

private $subscribers = [
    AssetSubscriber::class,
    // ...
    DeletedUserSubscriber::class,
];

A continuación, aquí hay una función para instanciar a los suscriptores.

Estos bloques pueden ser parte de la misma función o pueden estar separados según sus necesidades.

Suscriptores

Como se mencionó, los suscriptores son la manera de:

1. Escuche un cierto gancho en WordPress
2. Envíe un Servicio para hacer cualquier trabajo que esté destinado para el gancho dado.

Así que suponga por un momento que desea hacer algo cada vez que se elimine un usuario. Desea crear una instancia de un servicio a través del suscriptor siempre que ocurra este gancho.

Foto de Lee Campbell en Unsplash

Como ejemplo:

Tenga en cuenta que el suscriptor conoce el servicio (aunque no depende de él, ya que es simplemente un intermediario entre WordPress y el servicio) y especifica el gancho en el servicio que está instanciando.

Servicios

Finalmente, los servicios son los objetos que hacen todo el trabajo pesado en un complemento. Esto significa que si necesitan leer o escribir en la base de datos, el sistema de archivos, la red, procesar datos, etc., todo sucede dentro de su contexto.

Foto de Erik Mclean en Unsplash

Pueden ser conscientes de otras clases, pueden no serlo. Pueden implementar una interfaz o una clase abstracta o no. Eso está realmente más allá del alcance de esta publicación. Pero el punto es que, usando el gancho de arriba como ejemplo, si quieres hacer algo cuando se elimina un usuario, lo haces dentro del servicio.

Por ejemplo:

class DeletedUserService
{
    public function add(string $hook)
    {
        add_action($hook, [$this, 'deletedUser'], 99, 1);
    }

    public function deletedUser(int $userId)
    {
        $user = get_userdata($userId);
        if (false === $user) {
            return;
        }

        // Do work with the user that's being deleted.   
    }
}

Y ese es el final. Una vez que se ejecute el servicio, el control volverá a WordPress y la aplicación continuará ejecutándose normalmente.

Todos juntos ahora

Suponiendo que tiene un archivo de arranque para su complemento, que la mayoría hace, ya que aquí es donde se define el complemento requerido, se requiere un cargador automático y se produce la creación de instancias del complemento en sí.