¿Cuál es la principal ventaja de un bloque dinámico?

El bloque dinámico permite salida dependiente de estado real del sistema.

¿Qué patrón reduce más deuda entre shortcode y bloque?

Un renderer compartido evita inconsistencias y simplifica mantenimiento.

Bloque dinámico en Gutenberg: reutilizar lógica sin duplicar código

Transformas la lógica del shortcode en un bloque dinámico robusto, con render en servidor, seguridad y arquitectura reutilizable para crecer sin deuda técnica.

¿Cuánto sabes de WordPress Plugin?

📘 Teoría

Cuándo usar bloque dinámico y no bloque estático

Si la salida depende de datos vivos, contexto o permisos, necesitas render en servidor.

Un bloque estático guarda HTML en el contenido. Funciona bien para piezas editoriales fijas.

Un bloque dinámico ejecuta callback PHP al renderizar, ideal cuando el contenido depende de opciones del plugin, usuario actual, fecha o estado.

Caso real: avisos legales por país/rol no pueden resolverse con HTML fijo sin duplicar contenido manual.

Estático: contenido fijo y simple.
Dinámico: reglas de negocio y contexto.
Para plugins: dinámico suele ser la opción más sólida.

Arquitectura limpia: renderer compartido

No dupliques lógica entre shortcode y bloque.

Extrae la generación de salida a una función o clase (`NoticeRenderer`) y reutilízala desde todos los canales.

Así, cuando cambias una regla (por ejemplo, audiencia o tono), la modificación se aplica en bloque y shortcode automáticamente.

Este patrón reduce bugs por divergencia y facilita testing.

Renderer compartido entre shortcode y bloque

function wpac_render_notice(array $atts = []): string {
    $atts = wp_parse_args($atts, [
        'tone' => 'info',
        'title' => '',
    ]);

    $allowed = ['info', 'warning', 'success'];
    if (!in_array($atts['tone'], $allowed, true)) {
        $atts['tone'] = 'info';
    }

    return '<div class="wpac wpac-' . esc_attr($atts['tone']) . '">'
        . esc_html($atts['title'])
        . '</div>';
}

add_shortcode('wpac_notice', fn($atts) => wpac_render_notice((array) $atts));

Registrar bloque dinámico con `render_callback`

El callback de render debe ser seguro, corto y predecible.

Registra el bloque en `init` y delega todo a tu renderer compartido.

Valida atributos entrantes con whitelist y aplica valores por defecto.

Devuelve siempre string; evita `echo` directo dentro del callback.

Error frecuente

Render callback con lógica de negocio extensa.

Difícil de mantener.
Más riesgo de incoherencias.
Peor testabilidad.

Patrón recomendado

Callback mínimo + renderer dedicado.

Más claridad.
Menos duplicidad.
Evolución más fácil.

Rendimiento del bloque dinámico

Dinámico no significa lento si diseñas caché y consultas bien.

Si el resultado cambia poco, cachea HTML por contexto (por ejemplo, por rol o idioma) con transients.

Evita consultas caras por cada render del bloque en páginas con muchos elementos.

Mide impacto en TTFB al activar el bloque en plantillas de alto tráfico.

1 Cuándo usar bloque dinámico y no bloque estático 2 Arquitectura limpia: renderer compartido 3 Registrar bloque dinámico con `render_callback` 4 Rendimiento del bloque dinámico

🧪 Aprende probando

Ejemplo Ejemplo guiado: registrar bloque con metadata y render callback Configuramos un bloque dinámico que reutiliza el renderer del plugin.

⌄

🏁 Retos

Reto Reto real: añadir atributo `audience` y fallback seguro Extiende el bloque para soportar segmentación básica sin romper render existente.

⌄

🧰 Recursos

Enlaces útiles

Block Editor Handbook register_block_type() Creating Dynamic Blocks WordPress Plugin: hooks y shortcode WordPress: Gutenberg fundamentos WordPress Plugin: AJAX y REST

Test

Comprueba tus conocimientos con un test sobre WordPress Plugin.

Test de WordPress Plugin

Recursos del curso 15

📘 Glosario 🎬 Vídeos 🔗 Enlaces

‹

Lección 11

Assets y UX en admin: carga selectiva y panel de ajustes más usable

Lección 13

WP-Cron en plugins: tareas programadas sin sorpresas en producción

›