Meglio sparare hook specifici o hook generici con parametri?

Sto creando un modulo plug-in per gestire i moduli che possono essere agganciati utilizzando azioni / filtri dagli sviluppatori.

Il mio plug-in deve essere in grado di gestire forme diverse con diversi set di filtri e vedo 2 modi per farlo.

Metodo 1

Fuoco di ganci specifici per ogni forma.

Quindi codice come questo potrebbe essere chiamato forma all'interno del mio plugin:

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

E potrebbe essere usato così:

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

    return $errors;
} 10, 2)

Metodo 2

Passa un parametro alla funzione chiamante.

Quindi codice come questo potrebbe essere chiamato forma all'interno del mio plugin:

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

E potrebbe essere usato così:

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)

Ci sono esempi nel core di WordPress in cui questo tipo di problema viene affrontato?

Esiste un metodo preferito per affrontare questo?

Il metodo 1 è molto più robusto ed estendibile, secondo me.

Metodo 1: per aggiungere o rimuovere moduli o altre funzionalità, è sufficiente aggiungere o rimuovere funzioni. In particolare, puoi farlo da altri file, come moduli separati del tuo plugin o altri plugin esterni. Penso che questo sia l'argomento principale a suo favore: estensibilità e modularità.

Metodo 2: per aggiungere o rimuovere moduli o altre funzionalità è necessario modificare una funzione esistente, che è molto più soggetta a bug. Un'istruzione switch come quella del metodo 2 si sfugge facilmente. L'elenco dei casi può richiedere molto tempo ed è facile introdurre bug non appena si hanno diversi filtri con lo stesso tipo di istruzione switch. Ad esempio, potresti voler filtri per la convalida, la visualizzazione di moduli vuoti da compilare, la visualizzazione del contenuto dei moduli compilati, la gestione del database, ... Quindi ora hai un sacco di funzioni ognuna con un elenco molto lungo di casi di commutazione , che devi mantenere sincronizzato.

(Ho avuto una brutta esperienza di questo con un'estensione popolare per le forme di gravità - non è ingestibile se sei disciplinato, ad esempio mantenere l'elenco dei casi nello stesso ordine in tutte le funzioni, ma non è nemmeno carino.)

Individuazione dei bug: Molto più facile con il Metodo 1: il colpevole sarà di solito il filtro o la forma appena aggiunti, piuttosto che alcuni errori di battitura introdotti inavvertitamente in quella lunghissima funzione del Metodo 2.

Esempi: troverai tantissimi esempi del Metodo 1 nel core di wordpress (ad es. Https://developer.wordpress.org/?s=post+type&post_type[[=wp-parser-hook ), ma non ricordo una singola istanza del Metodo 2.

Rendi il nome hook specifico per quello che fa, non dove viene chiamato. Non passare più parametri, perché non è facile estenderlo. Passa invece un oggetto parametro.

Esempio

Creare l'oggetto parametro con un'interfaccia per l'iniezione delle dipendenze:

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'] ]
);

Ora passalo nel filtro:

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

Uno sviluppatore di terze parti può leggerlo ora, ma non modificarlo, quindi gli altri possono fare affidamento sulla sua struttura, perché non c'è modo di corromperlo.

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