Estamos teniendo un muy buen progreso - Deberías estar orgulloso!
Veamos qué archivos hemos modificado: Agrega todo. Y haz commit, Porque ahora quiero
instalar una de mis herramientas de symfony favoritas.
Corre: composer require profiler -- dev. Estoy usando --dev
porque el profiler es una herramienta
que sólo necesitaremos mientras estamos en desarrollo: No será usada en producción.
Esto significa que Composer lo agrega a la sección require-dev de composer.json.
No es tan importante, pero es la forma correcta de hacerlo.
Y... en este punto, no debería sorprendernos que esto ha instalado una receta!
Corre: git status. Oh, wow!
Agregó tres archivos de configuración.
Gracias a éstos, el módulo funcionará al instante.
Pruébalo: de vuelta a tu navegador, refresca la página.
Saluda a la barra de herramientas debug!
La dichosa barrita en la parte inferior.
Ahora esto aparecerá en cada página HTML mientras estamos desarrollando.
Nos muestra el código de status, cuál controlador y ruta usamos, velocidad, memoria, llamadas Twig
e incluso más íconos aparecerán a medida que empezamos a usar más partes de symfony.
La mejor parte es que puedes hacer click en cualquier de estos íconos para saltar...
al profiler.
Esta es básicamente la version expandida de la barra de herramientas y está llena de información
sobre la carga de la página, incluyendo la información del request, response
e incluso una maravillosa pestaña de performance.
Esta no solo es una buena manera de hacer un debug del performance
de tu aplicación, también es una gran manera...
de simplemente entender qué está sucediendo dentro de Symfony.
Hay otras secciones para Twig, configuración,
cacheo y eventualmente habrá una pestaña para ver las queries a la base de datos.
A propósito, esto no es solo para páginas HTML: también puedes acceder al profiler
para las llamadas AJAX que haces a tu app.
Te mostraré cómo más adelante.
Cuando instalamos el profiler, también obtuvimos otra herramienta útil llamada dump().
Haré click en atrás un par de veces para ir a la página.
Abre el controlador: src/Controller/QuestionController.php.
Imagina que queremos ver una variable.
Normalmente, usaría var_dump().
En vez de ello, usa dump() y vamos a imprimir el $slug y...
qué tal el propio objeto $this.
Cuando refrescamos, órale!
Funciona exactamente como var_dump() excepto...
muchísimo más bello y útil.
El controlador aparentemente tiene una propiedad llamada container...
y podemos ir más y más profundo.
Y si eres muy haragán...
Cómo la mayoría de nosotros lo es...
también puedes usar dd() lo cual significa dump() y luego die().
Ahora cuando refrescamos...
hace el dump, pero también termina la ejecución en la página.
Hemos perfeccionado el desarrollo basado en dump-and-die
Creo que deberíamos estar orgullosos?
Cámbialo de vuelta a dump()...
y sólo hagamos dump($this).
Hay otra librería que podemos instalar para herramientas de debug.
Esta es menos importante - pero de todas formas buena para tener en cuenta.
En tu terminal, corre: composer require debug Esta vez no estoy usando -- dev
porque esto instalará algo que sí quiero en producción.
Esto instala el DebugBundle - eso no es algo que necesitemos en producción -
pero también instala Monolog, que es una librería de logueo.
Y probablemente sí querramos loguear cosas en producción.
Antes de hablar de lo que esto nos dió, hecha un vistazo al nombre
del paquete que instaló: debug-pack.
Esta no es la primera vez que hemos instalado una librería con "pack" en su nombre.
Un "pack" es un concepto especial en Symfony: Es como un tipo de paquete "falso" cuya única función es
ayudar a instalar varios paquetes al mismo tiempo.
Echale un vistazo: copia el nombre del paquete, busca tu navegador,
y ve a https://github.com/symfony/debug-pack.
Orale! No es nada más que un archivo composer.json!
Esto nos da una manera fácil de instalar solo este paquete...
pero en realidad obtener todas estas librerías.
Así que gracias a esto, tenemos dos nuevas cosas en nuestra aplicación.
La primera es un logguer!
Si refrescamos la página...
y hacemos click en el profiler, tenemos la sección "Logs"
que nos muestra todos los logs para este request.
Estos también son guardados en el archivo var/log/dev.log
La segunda cosa nueva en nuestra aplicación es...
bueno... si miraste atentamente, el dump() desapareció de la página!
El DebugBundle integra la función dump() incluso más dentro de Symfony.
Ahora si usamos dump(), en vez de imprimirlo en la mitad de la página,
lo pone aquí abajo en la barra de herramientas debug.
Puedes hacer click en ella para ver una versión más grande.
No es tan importante...
Es solo otro ejemplo de cómo Symfony se vuelve más listo a medida que instalas más cosas.
Oh, ya que estamos hablando de ello,
el DebugBundle nos dió un nuevo comando de la consola.
En tu terminal, corre: php bin/console server:dump Esto inicia un pequeño servidor
detrás de escena.
Ahora, siempre que se ejecute dump() en nuestro código, aún se muestra en nuestra barra de herramientas...
Pero también se imprime en la terminal!
Esa es una excelente manera de ver información pedida en los requests de AJAX.
Presionaré Control-C para detenerlo.
Oh, y hablando de estos "packs", si abres el archivo composer.json,
el único problema con los packs es que aquí sólo vemos debug-pack version 1.0:
no podemos controlar las versiones de los paquetes de dentro.
Simplemente obtienes cualquiera que sea la versión que el pack solicita.
Si necesitas mas control, no hay problema...
Sólo extrae el pack: composer unpack symfony/debug-pack
Eso hace exactamente lo que esperas: quita debug-pack de composer.json
y agrega los paquetes subyacentes, como debug-bundle y monolog.
Ah, y como el profiler-pack es una dependencia
del debug-pack, está en ambos lugares.
Removeré el extra del require.
A continuación, hagamos nuestro sitio más bello incluyendo CSS en nuestra aplicación.