Cuándo usar las subacciones de WordPress (¿y qué son?)
Recientemente pasé por el proceso de usar un constructor de clase para evitar que un complemento funcione si no se carga una dependencia esperada.
Aunque no considero que esta estrategia en particular sea un problema para una dependencia única o en ciertas situaciones, hay formas en que esto puede conducir a olores de código.
También nos impide usar una función nativa de Core llamada subacciones de WordPress:
https://twitter.com/JJJ/status/822265137935646720
Pero antes de analizar las subacciones, quiero asegurarme de tener claros los problemas que se pueden generar con el uso del enfoque condicional (frente a las subacciones) con olores de código.
Subacciones de WordPress
Hay muchas formas en que se pueden explicar los olores del código, pero mi forma favorita proviene de Martin Fowler :
…los olores son ciertas estructuras en el código que indican una violación de los principios fundamentales del diseño y tienen un impacto negativo en la calidad del diseño.
Hay otra gran página sobre olores de código en Source Making que recomiendo leer si tienes la oportunidad.
Y la forma en que los condicionales pueden conducir a errores de código es simple: tiene el potencial de ensuciar su código con un conjunto masivo de declaraciones que incluyen muchas comprobaciones class_exists.
Y eso es un problema.
Cada vez que introduce otra dependencia en su código, termina agregando otra verificación condicional para ver si una clase está presente en la aplicación de WordPress.
Creo que está bien hacer esto con una sola dependencia, tal vez incluso dos dependencias, y si está trabajando "lo suficientemente alto" en su arquitectura, pero esta no es la forma de manejar esto correctamente con muchas dependencias ni en un nivel inferior en tu complemento
Ahí es donde las subacciones de WordPress entran en escena. Puede ver una lista de subacciones en el tweet a través de John arriba.
También hay una definición oficial de subacciones en el bbPress Codex :
Estas acciones internas pueden considerarse como "subacciones" y le permiten agregar o reordenar acciones de WordPress según sea necesario para los complementos que dependen de bbPress.
Y puedes ver un ejemplo de ello en este archivo.
Claro, esta definición es específica de bbPress, pero eso no significa que no sea aplicable a lo que hacemos en WordPress.
Caso en cuestión: si alguna vez usó do_action para definir una acción personalizada, o si aprovechó un enlace proporcionado por otra persona fuera del núcleo de WordPress, entonces está familiarizado con la estrategia de implementar una acción secundaria.
En otras palabras, las subacciones de WordPress son simplemente acciones que podemos usar para cambiar el orden en el que nuestro complemento depende de otro complemento.
La forma en que esto se implementa puede variar dentro del contexto de su trabajo, pero podría decirse que la forma más popular y "correcta" de WordPress de hacerlo es aprovechar el argumento de prioridad para cuando se carga su complemento.
Es decir, tome la prioridad de la dependencia y asegúrese de que sea anterior a la activación de su complemento.
Hay métodos alternativos que se pueden usar, como cambiar el comportamiento de los complementos cada vez que están activados o no, pero esto está fuera del alcance de esta publicación en particular y puede alterar negativamente la experiencia del usuario (de WordPress en general, nada menos).
Independientemente, el punto es que cuando se trata de usar subacciones de WordPress, programación orientada a objetos y administración de dependencias de terceros, asegúrese de que las decisiones que está tomando no dañen el diseño de su código.
Si tiene sentido verificar la existencia de una clase, está bien, pero si tiene más sentido esperar hasta que un conjunto de clases o complementos se hayan cargado antes que el suyo, entonces las subacciones de WordPress probablemente tengan más sentido.