¿Es mejor disparar ganchos específicos o ganchos genéricos con parámetros?

Estoy creando un complemento de formulario para manejar formularios que los desarrolladores pueden conectar con acciones / filtros.

Mi complemento debe ser capaz de manejar diferentes formas con diferentes conjuntos de filtros y veo 2 formas de hacerlo.

Método 1

Fuego de ganchos específicos para cada forma.

Entonces, un código como este podría llamarse formulario dentro de mi complemento:

$formId = 'contact';
$errors = apply_filters('forms_validate_' . $formId, $errors, $data);

Y podría usarse así:

add_filter('forms_validate_contact', function($errors, $data){
    if(empty($data['name'])){
        $errors['name'] = 'Name is required';
    }

    return $errors;
} 10, 2)

Método 2

Pase un parámetro a la función de llamada.

Entonces, un código como este podría llamarse formulario dentro de mi complemento:

$formId = 'contact';
$errors = apply_filters('forms_validate', $formId, $errors, $data);

Y podría usarse así:

add_filter('forms_validate', function($formId, $error, $data){
    switch($formId){
        case 'contact':
            if(empty($data['name'])){
                $errors['name'] = 'Name is required';
            }
        break;
    }

    return $errors;
}, 10, 3)

¿Hay algún ejemplo en el núcleo de WordPress donde se aborde este tipo de problema?

¿Existe un método preferido para lidiar con esto?

El método 1 es mucho más robusto y extensible, en mi opinión.

Método 1: para agregar o eliminar formularios u otra funcionalidad, simplemente agregue o elimine funciones. En particular, puede hacerlo desde otros archivos, como módulos separados de su complemento u otros complementos externos. Creo que este es el argumento principal a su favor: extensibilidad y modularidad.

Método 2: para agregar o eliminar formularios u otra funcionalidad, debe modificar una función existente, que es mucho más propensa a errores. Una declaración de cambio como la del método 2 se sale de control fácilmente. La lista de casos puede ser muy larga y es fácil introducir errores tan pronto como tenga varios filtros con el mismo tipo de declaración de cambio. Por ejemplo, es posible que desee filtros de validación, visualización de formularios vacíos para rellenar, visualización del contenido de formularios completados, gestión de bases de datos, ... Así que ahora tiene un montón de funciones, cada una con una lista muy larga de casos de cambio , que tienes que mantener sincronizado.

(Tuve una mala experiencia de esto con una extensión popular para las formas de gravedad: no es inmanejable si eres disciplinado, por ejemplo, mantén la lista de casos en el mismo orden en todas las funciones, pero tampoco es bonita).

Localización de errores: mucho más fácil con el Método 1: el culpable generalmente será el filtro o la forma recién agregados, en lugar de algún error tipográfico introducido inadvertidamente en esa función tan larga del Método 2.

Ejemplos: encontrará toneladas de ejemplos del Método 1 en el núcleo de WordPress (por ejemplo, https://developer.wordpress.org/?s=post+type&post_type[[=wp-parser-hook ), pero no recuerdo Una sola instancia del Método 2.

Haga que el nombre del gancho sea específico para lo que hace, no donde se llama. No pase múltiples parámetros, porque eso no es fácil de extender. Pase un objeto de parámetro en su lugar.

Ejemplo

Cree el objeto de parámetro con una interfaz para inyección de dependencia:

interface Validation_Parameters {

    public function id();

    public function errors();

    // not a good name …
    public function details();
}

class Form_Validation_Parameters implements Validation_Parameters {

    private $id;

    private $errors;

    private $details;

    public function __construct( $id, $errors, $details ) {

        $this->id      = $id;
        $this->errors  = $errors;
        $this->details = $details;
    }

    public function id() {
        return $this->id;
    }

    public function errors() {
        return $this->errors;
    }

    public function details() {
        return $this->details;
    }
}

$params = new Form_Validation_Parameters( 
    'contact',
    new WP_Error(), // should be prepared better.
    [ 'request' => $_SERVER['REQUEST_URI'] ]
);

Ahora pásalo en tu filtro:

$valid = apply_filters( 'form_is_valid', TRUE, $params );

Un desarrollador externo puede leerlo ahora, pero no cambiarlo, por lo que los demás pueden confiar en su estructura, porque no hay forma de corromperlo.

add_filter( 'form_is_valid', function( $bool, Validation_Parameters $params ) {
    // do something and return a value
});