Widgets de WordPress: Refactorización, Parte 12

En lo que respecta a la refactorización de WordPress Widget Boilerplate, especialmente dado lo lejos que hemos llegado desde que comenzó el proyecto hace ocho años, hemos trabajado mucho.

Lo hemos llevado a un estándar mucho más moderno y estamos haciendo que sea mucho más fácil trabajar con él, de modo que la creación de widgets futuros debería ser más fácil. Y esto no es solo desde el estándar del repetitivo sino desde un estándar orientado a objetos para que el mantenimiento y la calidad del código sea mayor.

En la última publicación, terminamos gran parte del trabajo para el área de administración y estamos listos para comenzar nuestro trabajo en el código para el front-end.

Dijimos:

A continuación, veremos la representación de contenido en el front-end. Nos acercamos al final de la refactorización de Boilerplate, pero queda un poco más por hacer antes de que estemos listos para fusionarlo en la rama maestra de la base de código.

Entonces, en esta publicación, vamos a continuar allí. Ahora, si ha estado siguiendo hasta este punto, debería tener todo lo que necesita de la rama de desarrollo.

De lo contrario, asegúrese de tirar de él, ya que es donde vamos a continuar en el resto de la publicación.

El modelo de widget de WordPress: Refactorización Parte 12

Ahora, cuando se trata del front-end, es fácil pensar en el front-end como algo que el usuario ve frente a él, independientemente de si está en el área administrativa o no.

Sin embargo, esta serie ha dejado claro que estamos dividiendo lo que el usuario ve entre el área administrativa y el área pública del sitio.

Entonces, lo que vamos a hacer es trabajar en el área del código que brinda información para el usuario en el área pública del sitio. Vamos a empezar simplemente leyendo la información y mostrándola.

Luego, en la próxima publicación, veremos cómo trabajar con lógica condicional con respecto a algunas de las opciones para ver si hay algo que debamos hacer.

Dicho esto, pasemos al código.

Sobre los datos que mostraremos

Recuerde, el widget, en este punto, tiene tres cosas que influyen en su visualización:

1. el título del widget,
2. el contenido del widget,
3. una alternancia en cuanto a si debemos o no mostrar el título

La tercera opción es principalmente para mostrar cómo usar un tipo diferente de elemento. Porque, técnicamente, si no quisiéramos mostrar el título del widget, simplemente no pondríamos nada en el widget.

Pero creo que ayuda mostrar el uso de diferentes tipos de elementos y sus valores de una manera práctica (o semi-práctica).

De todos modos, dicho esto, sabemos que para cada instancia dada del widget, los datos se almacenan con el título ,  el contenido y  el nombre del título para mostrar y las ID proporcionadas por WordPress.

Por lo tanto, los usaremos en nuestro código frontal para mostrar los valores.

Preparación de las funciones de visualización

Normalmente, la  función de widget es responsable de mostrar la salida del widget. Pero una de las cosas que hemos estado tratando de hacer es separar las preocupaciones de nuestro widget en un conjunto de clases y funciones más enfocado.

Lo primero que queremos hacer es escribir una  clase WidgetDisplay que se encargará, como seguramente es evidente, de mostrar el contenido del widget.

Por ahora, esto incluirá incondicionalmente el título, el contenido y el valor de incluir o no el título. WordPress también pone a disposición cierto contenido, como el marcado, que debe aparecer antes y después del widget, por lo que nos aseguraremos de incluirlo también.

Pero primero, apaguemos la clase :

<?php

namespace WordPressWidgetBoilerplateWordPress;

class WidgetDisplay
{
  private $widgetSlug;

  public function __construct(string $widgetSlug)
  {
      $this->widgetSlug = $widgetSlug;
  }

  public function show($args, $instance)
  {
    // More to come
  }
}

Después de eso, debemos asegurarnos de que también lo estamos escribiendo para las otras clases. Primero, nos aseguraremos de incluirlo en nuestra clase Widget :

<?php
public function widget($args, $instance)
{
    return $this->widgetDisplay->show($args, $instance);
}

Y luego lo agregaremos a la clase WidgetAdmin (ya que aquí es donde residen las funciones principales de la API de Widget; simplemente delega la responsabilidad a la clase adecuada):

<?php

public function __construct($widgetSlug)
{
    parent::__construct($widgetSlug);
    $this->widgetSerializer = new WidgetSerializer($this->getWidgetSlug());
    $this->widgetDisplay = new WidgetDisplay($this->getWidgetSlug());
}

En este punto, no estamos mostrando nada todavía. Estamos cerca y nos centraremos en eso pronto.

Visualización de los datos

Suponiendo que pueda agregar el código anterior sin errores, es hora de mostrar el contenido del widget.

Podemos hacer esto de muchas maneras, desde un simple var_dump hasta trabajar para mostrar el contenido de una manera más fácil de usar. Y yo soy mucho más fan de este último.

Así que hagamos eso.

En la  función show de su  clase WidgetDisplay, agregue el siguiente código :

<?php
public function show($args, $instance)
{
    include_once 'Views/Widget.php';
}

Y luego la vista de la plantilla puede ser tan simple como esto :

<div id="<?php echo $args['id']; ?>">
    <h3 class="widget-title"><?php echo $instance['title']; ?></h3>
    <p><?php echo $instance['content']; ?></p>
    <pre><?php echo $instance['display-title']; ?></pre>
</div><!-- #<?php echo $args['id']; ?>-->

Esto asegurará que el marcado adecuado para todo el contenido antes del widget, el contenido del widget y el contenido se represente correctamente.

Una vez más, recuerde que estamos mostrando contenido que no estará en la versión final de esto, pero nos estamos acercando y lo abordaremos en la próxima publicación.

Recomendaría jugar con la  opción Mostrar título para ver cómo se representa en el front-end dado el marcado que proporcionamos.

Por ahora, la salida del widget debería verse así:

Pero eso es todo lo que hay que cubrir en esta publicación.

Hacia el refactor final

Lo último que vamos a ver después de esto es reforzar algo de la lógica condicional junto con una palabra sobre el almacenamiento en caché de datos (ya que ya estamos haciendo un poco de eso en publicaciones anteriores).

Sin embargo, por ahora, siéntase libre de jugar con lo que tenemos aquí junto con el código que no hemos incluido (como lo que se puede mostrar antes o después del widget).

Se han dejado deliberadamente fuera de este ejemplo, pero es posible que no siempre se omitan según el trabajo que esté haciendo.