The latest articles on DEV Community by Pablo Fumarola (@ajest). https://dev.to/ajest https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F446788%2F336532e8-7244-471a-b387-f419c8c5b9af.jpeg https://dev.to/ajest en Pablo Fumarola Mon, 07 Nov 2022 14:13:48 +0000 https://dev.to/ajest/de-html-a-pdf-2gmb https://dev.to/ajest/de-html-a-pdf-2gmb <p>Para todo aquel que esté necesitando crear archivos PDF de forma programática en base a contenido dinámico en un navegador web o con una API, comparto mi experiencia y las conclusiones que fui sacando en base a la rápida investigación que realicé y en las prueba que hice.</p> <p>Podemos decir que este problema se puede resolver de varias formas:</p> <ol> <li>"Imprimir" la página entera que queremos transformar en PDF (del lado del cliente).</li> <li>Utilizar una librería llamada html2pdf (del lado del cliente).</li> <li>Utilizar una librería llamada jsPDF (del lado del cliente y del servidor)</li> <li>Utilizar un paquete de PHP llamado DOMPDF (del lado del servidor)</li> </ol> <p>Analicemos estas posibles soluciones y sus pros y contras:</p> <h2> 1.- Imprimir </h2> <p><a href="https://res.cloudinary.com/practicaldev/image/fetch/s--p3x2OP3k--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://dev-to-uploads.s3.amazonaws.com/uploads/articles/1fn9kpu995q7h694j9r0.png" class="article-body-image-wrapper"><img src="https://res.cloudinary.com/practicaldev/image/fetch/s--p3x2OP3k--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://dev-to-uploads.s3.amazonaws.com/uploads/articles/1fn9kpu995q7h694j9r0.png" alt="Ejemplo de Mercado Libre " width="880" height="545"></a></p> <p>El primer enfoque quizás pueda ser el más fácil. Podemos maquetar la página con la tecnología que se nos ocurra para que luego el navegador y su opción de "Guardar como PDF" haga el resto.</p> <p>Pros:</p> <ul> <li>No necesitamos instalar ninguna dependencia</li> <li>El navegador intentará "renderizar" aquello que es texto como tal (etiquetas a, p, h1, h2, etc)</li> </ul> <p>Contras:</p> <ul> <li>Los sistemas operativos brindarán distintas opciones a la hora de elegir esta opción, esto significa que incluso puede no aparecer la opción "Guardar como PDF"</li> <li>Muchas veces el menú de "Imprimir" ofrecerá distintos tamaños de hoja, lo que hará que nuestra maqueta tenga que adaptarse a muchos tipos de tamaño si queremos evitar que alguien cree un archivo PDF que se rompa. Los tamaños pueden ser muy variados</li> <li>Si bien mencionamos como un punto a favor la capacidad del navegador de entender qué es un texto y renderizarlo como tal, esta funcionalidad no es perfecta. Se verá afectada por las reglas CSS que estemos usando</li> <li>El menú de imprimir no es un mini navegador, es decir que interpretará las instrucciones CSS de forma distinta que nuestra navegador, y esto incluso variará de navegador a navegador, así que hacerlo compatible requerirá de que trabajemos con muchos navegadores relevantes para nosotros</li> <li>Esta funcionalidad es del lado del cliente y requiere que estemos en la página en sí, no podemos automatizarlo de forma sencilla, quizás habría que utilizar alguna herramienta del tipo Puppeteer o Playwright o levantar un popup de html</li> <li>Requiere dos o tres clicks hasta obtener el resultado deseado lo cual puede ser molesto e incluso imposible de entender para algunos usuarios</li> </ul> <p>Por último, se debe mencionar que ya que el menú de imprimir no interpretará de forma perfecta nuestro CSS, lo más posible es que tengamos que crear otro documento de CSS especialmente diseñado para imprimir. Esto no es necesariamente algo negativo, por eso no está dentro del listado de contras, pero sí que generará la necesidad de hacer algo de trabajo extra.</p> <h2> 2.- html2pdf </h2> <p><a href="https://res.cloudinary.com/practicaldev/image/fetch/s--fhubhDj0--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://dev-to-uploads.s3.amazonaws.com/uploads/articles/sf1z2dyfmern2rkjc8qs.png" class="article-body-image-wrapper"><img src="https://res.cloudinary.com/practicaldev/image/fetch/s--fhubhDj0--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://dev-to-uploads.s3.amazonaws.com/uploads/articles/sf1z2dyfmern2rkjc8qs.png" alt="html2pdf" width="880" height="375"></a></p> <p>Esta librería escrita en Javascript está disponible en <em>npmjs</em> (<a href="https://www.npmjs.com/package/html2pdf.js/v/0.9.0">https://www.npmjs.com/package/html2pdf.js/v/0.9.0</a>). Es en una herramienta para tomar lo que aparece en la página y exportarla a PDF. La técnica que usa es, dicho de forma coloquial, sacarle una "foto" a la página utilizando canvas, crear una imagen e incrustarla en el archivo PDF resultante.</p> <p>Pros:</p> <ul> <li>Podemos usar la maqueta y tecnología que más nos guste ya que esta librería se encargará de que llegue al PDF de forma idéntica. (Hay excepciones)</li> </ul> <p>Contras:</p> <ul> <li>Al ser una suerte de imagen incrustada en el archivo PDF, las piezas de nuestra composición que sean TEXTO no se renderizará como tal, con todo lo que eso implica, por ejemplo que se pixelará al hacer Zoom. (Los links sí funcionan)</li> <li>Si bien el concepto es bastante simple, se requiere entender y ajustar las opciones de configuración de esta librería para obtener el resultado deseado.</li> <li>Las imágenes deben contemplar el problema de CORS, para lo cual muchos sencillamente optan por utilizar imágenes vía base64</li> </ul> <h2> 3.- jsPDF </h2> <p><a href="https://res.cloudinary.com/practicaldev/image/fetch/s--UmaQscp3--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://dev-to-uploads.s3.amazonaws.com/uploads/articles/4w2jiz1fx8ev0qnnj993.png" class="article-body-image-wrapper"><img src="https://res.cloudinary.com/practicaldev/image/fetch/s--UmaQscp3--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://dev-to-uploads.s3.amazonaws.com/uploads/articles/4w2jiz1fx8ev0qnnj993.png" alt="jsPDF" width="588" height="267"></a></p> <p>Otra librería para la creación de documentos PDF, pero en este caso no solo depende de una página sino que también se puede crear un documento de forma programática utilizando la API provista. (<a href="https://parall.ax/products/jspdf">https://parall.ax/products/jspdf</a>).</p> <p>Pros:</p> <ul> <li>Permite dos enfoques para resolver el mismo problema, lo cuál puede ser conveniente en algún caso</li> <li>Podemos usar la maqueta y tecnología que más nos guste ya que esta librería se encargará de que llegue al PDF de forma idéntica, ya que tiene la capacidad de utilizar la misma técnica de convertir la página a CANVAS para luego crear el documento deseado</li> <li>Es una librería muy utilizada y tiene buen soporte, está vigente</li> <li>Tiene una opción que intenta resolver el problema de textos cortados a la mitad cuando pasamos de una página a otra</li> <li>Se puede utilizar en Node.js</li> </ul> <p>Contras:</p> <ul> <li>Si se decide utilizar la funcionalidad de crear el documento en base a la API provista, no será tan fácil crear composiciones complejas que quizás con tecnologías web sí es más sencillo de resolver</li> </ul> <h2> 4.- DOMPDF </h2> <p>Ya que hablamos de tecnologías web, hablemos de PHP. Si necesitamos una solución similar a la de jsPDF pero del lado del servidor y con PHP, este es el paquete a elegir. Incluso tiene una adaptación para que se instale sin problemas en Laravel. Este es el sitio oficial: <a href="https://dompdf.github.io/">https://dompdf.github.io/</a><br> Este paquete puede ser utilizando con dos enfoques: Crear el documento con la API que nos provee (similar a jsPDF) ó crearlo en base a un HTML que le proveamos, no convertirá el HTML en canvas pero intentará resolver las piezas visuales que aparezcan.</p> <p>Pros:</p> <ul> <li>Permite dos enfoques para resolver el mismo problema, lo cuál puede ser conveniente en algún caso</li> <li>Es una librería muy utilizada y tiene buen soporte, está vigente</li> <li>La transformación de HTML a PDF contempla el correcto renderizado de los textos excepto para elementos de formularios (inputs, textareas, etc)</li> <li>Puede resolver el problema de textos cortados a la mitad cuando pasamos de una página a otra</li> </ul> <p>Contras:</p> <ul> <li>La compatibilidad con CSS es oficialmente la de CSS 2.1 y no de CSS3, aunque es cierto que sí interpreta bien algunas cosas de CSS3.</li> <li>Si se decide utilizar la funcionalidad de crear el documento en base a la API provista, no será tan fácil crear composiciones complejas que quizás con tecnologías web sí es más sencillo de resolver</li> </ul> <h2> Otras alternativas </h2> <ul> <li>Browsershot <a href="https://github.com/spatie/browsershot">https://github.com/spatie/browsershot</a> </li> </ul> <h2> Conclusión </h2> <p>Quizás la conclusión más sencilla sería la de utilizar jsPDF, pero eso dependerá más factores relacionados con el scope y características del proyecto en el que estamos trabajando.<br> Espero que este breve artículo pueda ser útil para aquel que esté necesitando una guía rápida y sencilla de esta funcionalidad.<br> Otro buen recurso es una pregunta que hicieron en stackoverflow (en inglés): <a href="https://stackoverflow.com/questions/18191893/generate-pdf-from-html-in-div-using-javascript">https://stackoverflow.com/questions/18191893/generate-pdf-from-html-in-div-using-javascript</a><br> Este recurso tiene incluso algunos ejemplos de implementación y técnicas para evitar algunos problema de las soluciones antes mencionadas. </p> javascript html webdev php Pablo Fumarola Thu, 22 Apr 2021 23:26:08 +0000 https://dev.to/ajest/estimado-programador-estas-usando-tests-3i0i https://dev.to/ajest/estimado-programador-estas-usando-tests-3i0i <p>Una vez pregunté a un programador experimentado y conocido en la industria: Puede un sistema mediano / grande estar "bien hecho" sin el uso de testing automatizado?</p> <p>El respondió que sí. Personalmente he conocido muy buenos programadores que, aún sin usar testing en lo absoluto, al destacar en la "consistencia" de sus diseños y convenciones de trabajo, entregaban buenas piezas de software. La pregunta que surge es: Es esto aplicable a un equipo de 5, 10 o más personas? Difícil responder sí.</p> <p>Eso nos lleva a la realidad de que eminencias de la industria dirán que no se puede pensar en la idea de un sistema bien realizado sin el apoyo de una buena suite de tests.</p> <p>Es innegable que, cuando contamos con el respaldo de tests automatizados, no solo el sistema con el que trabajamos es más confiable, sino que el uso de los mismos nos obliga a mejorar nuestros diseños de software.</p> <p>Por esa razón, comparto algunas preguntas junto a sus modestas respuestas para los que recién se acercan a este mundo:</p> <h1> 1 - Por qué debo testear? </h1> <p>Los tests nos protegen contra los bugs (sí, es muy posible que estés lidiando con muchos bugs y por eso te estés acercando al mundo del testing), nos ahorra tiempo en el corto o mediano plazo, nos ayudan a pensar más en el diseño de nuestra sistema, en muchos casos nos suben el nivel técnico y por ende nos profesionaliza. Hay que detenerse un poco a pensar en todos los beneficios que esto conlleva, no son pocos.</p> <h1> 2 - Cuáles son los tipos de tests más usados? </h1> <p><em>Test de Aceptación ó e2e (End to End):</em> Estos son aquellos que probarán nuestro sistema desde cada punto de entrada deseado, tratando de que este recorra la mayor cantidad posible del circuito de nuestro sistema. El objetivo es que interactúe con todos los elementos necesarios, conectándose a sistemas externos y levantado todos los servicios necesarios para su funcionamiento como si lo estuviese usando el "usuario final".</p> <p><em>Test de Integración:</em> Este tipo de test probará como se integra nuestro sistema con otros sistemas externos. Un ejemplo es la base de datos. Otro ejemplo sería que un módulo de nuestro sistema se conecta a otro. Prueba circuitos más específicos y normalmente más cortos que los e2e.</p> <p><em>Test Unitario:</em> Este tipo de test, como su nombre lo indica, probará unidades de comportamiento de forma independiente. Tiene como propósito concentrarse en el modelo de negocio de nuestro sistema en vez de en cómo se integra a otros servicios. Trata de atacar a la lógica fundamental, el core del negocio, del sistema con el que trabajamos.</p> <h1> 3 - Cómo deben ser los test? </h1> <p>Deben ser simples, puntuales, fáciles de entender, descriptivos. Un solo método debería poder resolver toda la lógica, no debería esconderse ninguna lógica. No debe saber muchos detalles de implementación del componente ó sistema bajo test. Los tests suelen tener una misma fisionomía, una separación en tres grandes pasos (AAA): Arrange (Armado), Action (Acción), Assert (Afirmar).</p> <h1> 4 - Qué debo testear? </h1> <p>Debemos esforzarnos por testear, de forma directa o indirecta todos los flujos de nuestro sistema. El énfasis debe ser puesto en la lógica de negocio, en las piezas de nuestro software más importantes.</p> <p>Programar tests lleva tiempo, al principio no es fácil, y puede que lo hayamos intentado en más de una ocasión sin éxito. La clave está en perseverar y en entender que vale la pena el esfuerzo.</p> testing programming design