Por qué elegí Angular para acortar URL | trucos CSS
Los acortadores de URL son herramientas que utilizamos para hacer que los enlaces sean más cortos de lo que realmente son. Con los acortadores de URL, puede transformar un enlace largo (tal vez para un formulario de registro o un artículo) en una versión más corta.
Detrás de escena, las versiones larga y corta de un enlace determinado se almacenaban en alguna base de datos. Luego, cuando el usuario visita el enlace corto en un navegador, el acortador de URL redirigirá al usuario a la versión larga del enlace (donde se encuentra el contenido real).
Los enlaces acortados de los acortadores de URL generalmente se usan cuando la versión larga de esos enlaces sería demasiado larga para usar. Compartir enlaces en las redes sociales o diseñar folletos y anuncios es un uso popular de los acortadores de URL.
Para uno de mis proyectos, creé un acortador de URL personal. Mi intención era usarlo para enlazar a artículos que escribo o videos que hago. solía Firebase para construir el backend del acortador de URL. Específicamente, usé la base de datos de Firestore para almacenar versiones cortas y largas de cada enlace dado.
Para crear conexiones tuve que usar la consola Firebase. Esto no fue un problema, pero fue engorroso debido a la alta frecuencia de edición de enlaces. La experiencia de usuario (UX) no era ideal. Ahora me encontré con un problema. ¿Cómo creo, edito y elimino enlaces? Necesitaba crear una interfaz para el acortador de URL. Necesitaba un sitio web para esto.
En este artículo, revisaremos las herramientas disponibles que se usaron para construir esta interfaz, las opciones de solución y los factores que influyeron en por qué se crearon.
Planteamiento del problema
Los requisitos del proyecto eran:
- Plataforma/ArquitecturaIngeniería de proceso de codificación y estructura.
- Kit de herramientas de interfaz de usuarioComponentes a utilizar para las diferentes partes de la interfaz de usuario.
- ConvenienciaConstruir el backend no fue difícil, por lo que esta interfaz tampoco debería serlo. Quería un código limpio y un desarrollo rápido.
Solución de primera elección: Angular
Muchas ideas vienen a la mente cuando empezamos a crear una interfaz. En un sentido amplio, podríamos categorizar las opciones de construcción de interfaz en 3 plataformas:
- Creadores de sitios web, como WordPress, Wix, Squarespace y más.
- Vanilla Building - usando HTML simple, CSS y JavaScript.
- Marco de JavaScript: como React, Vue, Angular, etc.
Según mi experiencia, los creadores de sitios web ofrecen una colección muy limitada de widgets, componentes y plantillas. La mayoría de los creadores de sitios web no brindan una manera fácil de integrar un backend personalizado completo como Firebase. Si bien es posible crear sitios impresionantes conectando estas piezas, el nivel de complejidad de mi proyecto probablemente fue más allá de lo que normalmente brindan estos servicios.
Sería posible usar un estilo sin bordes o vainilla. Sin embargo, el factor decisivo que me hizo no ir por la ruta de la vainilla pura fue que la última versión no CDN del SDK de JavaScript de Firebase (versión 9) está diseñado con instalación a través de npm
o yarn
y empaquetar módulos en la mente.
Los marcos de JavaScript manejan las partes centrales de la interfaz (como el enrutamiento, el enlace de back-end, etc.) para reducir el esfuerzo del desarrollador. Hay muchos de ellos, y elegir cuál usar parecía una opción más difícil.
Hay muchos marcos de JavaScript para el desarrollo de front-end. Los ejemplos incluyen Angular, React, Vue, etc.
De los marcos disponibles, sé Angular más. Esto se debe a que lo he usado en proyectos anteriores como:
- Coro Carol Quiz: Un portal donde los examinados compitieron en dos rondas en línea de cuestionarios cronometrados sobre capítulos seleccionados de la Biblia.
- Comunidad Genesys AE-FUNAI: Un formulario personalizado donde los miembros del Genesys Campus Club AE-FUNAI (mi comunidad) reportan su progreso y comparten sus logros.
- Sistema de gestión de lecciones: Un panel sencillo para administrar las sesiones entre estudiantes y profesores.
Esta familiaridad me permite construir rápidamente con Angular. La capacidad de construir rápidamente no debe subestimarse.
Elegí Angular por su capacidad de programación orientada a objetos (POO). OOP es un paradigma de programación que se enfoca más en clases, datos o estados administrados que en la lógica que controla los datos, como es el caso de la programación funcional. La separación de problemas es una de las ventajas de usar OOP. En otras palabras, OOP permite la encapsulación. Le permite abarcar aspectos del programa en dominios o clases específicos.
En Angular, los componentes (y sus métodos de ciclo de vida) están encapsulados por clases de TypeScript. Te hace pensar de una manera OOP. El beneficio de OOP se refleja en cómo los componentes de Angular sirven como módulos de usuario reutilizables dentro del marco de Angular. De esta manera, verá un componente Angular como una especie de objeto autónomo que sigue siendo parte de un todo. Esto hace El desarrollo de la interfaz es fácil ya que diferentes partes de la aplicación de la interfaz pueden estar cubiertas por componentes y, por lo tanto, pueden usarse cuando sea necesario.
También elegí Angular porque usa TypeScript. TypeScript es JavaScript con características de un lenguaje de programación escrito. Casting en este contexto significa que una variable no puede cambiar el tipo de valor que almacena a lo largo de su vida. Por ejemplo, una variable que contiene una cadena no contendrá repentinamente un número mientras se usa en este programa. Escribir aumenta la calidad del código y reduce los errores.
Como resultado de su sistema de tipos, TypeScript reduce el tiempo dedicado a depurar aplicaciones Angular. Esto brinda experiencia a los desarrolladores, ya que tendrán más tiempo para crear la aplicación de interfaz. La depuración también se vuelve fácil para el programador.
Nota: Aquí hay más sobre la programación orientada a objetos con TypeScript
Aún así, sobre los beneficios de Angular, las aplicaciones Angular vienen como una configuración completa. Manejan funciones importantes como agrupar preprocesadores CSS o servicios Angular. Sin embargo, cuando usa Angular, no necesita configurar cada biblioteca de forma independiente, Angular se encarga de eso.
Un servicio Angular es lo que Angular usa para configurar la inyección de dependencia. En pocas palabras, la inyección de dependencia proporciona a la aplicación lo que necesita para funcionar (dependencias) sin que a la aplicación le importe cómo se obtuvieron las dependencias. También elegí Angular porque Firebase, por ejemplo, se proporcionará automáticamente a cualquier componente de Angular que lo necesite sin ninguna configuración adicional.
Las ventajas de la programación orientada a objetos, TypeScript y la inyección de dependencia hacen que Angular sea la opción preferida para el desarrollo front-end. Junto con el hecho de que ya estaba familiarizado con Angular, Angular me resultó más cómodo para este proyecto de acortamiento de URL.
Los artículos de Angular CSS-Tricks también son parte de la historia. Me dieron más confianza usando Angular.
La segunda opción de solución: Material Design
Después de elegir Angular, mi siguiente tarea fue considerar cómo manejaría la interfaz de usuario (UI).
Podría ignorarlo y hacer Vanilla CSS en su lugar, pero ¿por qué reinventar la rueda? Después de todo, eso anularía la razón para usar un marco de JavaScript: la conveniencia.
Al elegir un conjunto de herramientas de interfaz de usuario, parece haber un océano de posibilidades. Para nombrar algunos, uno puede usar Bootstrap, Bulma, Semantic UI, Tailwind, etc. Cada conjunto de herramientas tiene sus propias especificaciones y motivación.
Para el caso de uso de mi proyecto, Material Design lideró el paquete.
Uno de los factores más importantes fue el soporte de Angular y Material Design. Hay una especificación completa solo para Angular para Material en material.angular.io
(es como un subdominio de los propios documentos angulares).
Me decidí por Material Design porque se centra en los componentes. A diferencia de otros marcos CSS, no tiene clases auxiliares de CSS. Esto estuvo bien porque solo quería un conjunto de componentes (botones, íconos, entradas, barras laterales, snackbars, etc.) El material también agrega animaciones, ondas y efectos de sombra por sí mismo, lo que lo hace más conveniente desde otras bibliotecas.
Además, Angular Material tiene soporte de temas listo para usar, cuando inicializa Angular Material, tiene la opción de elegir un tema predefinido para toda la aplicación Angular o crear uno personalizado.
Para mayor comodidad, elegí un tema oscuro al configurar Angular Material.
La tercera opción de solución: Formas reactivas
Con un marco y un conjunto de herramientas en su lugar, centré mi atención en una de las características más importantes de un acortador de URL. El núcleo de la interfaz del acortador de URL es el formulario para crear y actualizar enlaces.
Llamemos a este formulario editor de enlaces El formulario del editor de enlaces tiene solo dos entradas, una para la versión corta del enlace y la otra para la URL completa a la que se redirigirá la versión corta.
Para la gestión de formularios, Angular viene con dos mecanismos. Entonces, en lugar de crear un formulario y manejar su validación y envío como se hace en HTML simple y JavaScript, debe usar una de las dos formas que proporciona Angular. Los dos métodos son:
- Formularios basados en plantillas
- formas reactivas
Formularios basados en plantillas como sugiere el nombre, incluye el código HTML (plantilla) que controla la mayor parte del formulario Angular. Este enfoque es preferible cuando su formulario no hace mucho o es desechable.
formas reactivaspor otro lado, proporcionar un enfoque basado en modelos para procesar entradas de formulario cuyos valores cambian con el tiempo. Necesitaba formularios reactivos porque este es el mismo formulario que usaré para editar varios enlaces en un momento dado.
Nota: Aquí hay más materiales sobre el uso de Reactive formularios
En este punto, los beneficios de la elección anterior comenzaron a mostrarse. El material angular tiene form-field
componentes form-field
envuelve la entrada como un componente y proporciona animaciones, efectos dominó y mensajes de error según sea necesario.
Así que lo usé para ambas entradas de formulario del editor.
La cuarta opción de solución: sábana bajera con cantonera y cajón
La solución final involucró cómo mejorar la experiencia del usuario. Un acortador de URL habría necesitado otras funciones, como ver todos los enlaces creados y analizarlos. Estas funciones requerían espacio en la pantalla, lo que me obligó a replantearme si había mejores soluciones para mostrar el editor de enlaces del formulario al usuario.
Si el usuario no necesita actualmente el formulario del editor de enlaces, tiene sentido que el formulario del editor de enlaces no siempre esté visible. Esto liberará espacio en la interfaz de usuario para otros elementos.
Sin embargo, dividir esta experiencia de usuario en dos páginas separadas se sintió disruptivo. En cambio, para abrir el editor de enlaces cuando sea necesario, agregué un botón de acción flotante en la página de creación de enlaces. Al hacer clic en él, el botón hará que se abra el formulario del editor en cualquier componente de la interfaz de usuario adecuado.
A bajeracomo sugiere el nombre, es un componente de la interfaz de usuario que se abre desde la parte inferior de la pantalla. Tiene contenido interactivo con el que el usuario puede trabajar. Cubre la vista de pantalla móvil actual (pero no la bloquea por completo).
Los pies de página generalmente se usan en lugar de ventanas emergentes si el usuario va a pasar mucho tiempo interactuando con su contenido. Por lo tanto, las hojas inferiores son adecuadas para abrir el editor de pantalla en dispositivos móviles. Sin embargo, interactuar con un pie de página es difícil cuando la pantalla es ancha. Necesitaba un componente de interfaz de usuario diferente para el formulario del editor de enlaces en pantallas anchas.
Cajones apertura lateral. Usar un cajón para abrir el formulario del editor de enlaces de pantalla ancha era la opción. Los cajones no serán buenos para el editor de pantalla móvil. El ancho de la pantalla será relativamente pequeño y el cajón puede bloquear completamente la pantalla (lo que no es deseable UX).
Elegí estos dos componentes de la interfaz de usuario de Material Design para que el formulario pudiera tener algún tipo de efecto receptivo. Entonces, ya sea en mi teléfono o computadora portátil, la creación de enlaces se realizará en un componente de interfaz de usuario apropiado.
En el código, Angular verifica si el dispositivo tiene un ancho de pantalla pequeño. Si es así, abre una subhoja que contiene el formulario del editor de enlaces. Por otro lado, si la pantalla es ancha, Angular abre un cajón que contiene la misma forma.
El uso de estos dos componentes resultó en una pequeña complicación. Si se gira mi teléfono o se reduce el ancho de la ventana del navegador de mi computadora portátil, el formulario se abre en el componente de interfaz de usuario opuesto. Es decir, en lugar de abrirse en un cajón del portátil, se abrirá en una hoja inferior (ya que se redujo el ancho del navegador).
Soporte, pruebas futuras, versiones futuras
Mientras pensaba en las oportunidades para iterar en este proyecto, encontré limitaciones con el caso de uso actual diseñado para admitir un solo administrador. Pero con la autenticación y las cuentas de usuario, puede admitir usuarios adicionales que administren conexiones y accedan a análisis.
En este caso, la selección de componentes anterior será adecuada.El editor de enlaces es receptivo, por lo que en cualquier dispositivo, los usuarios tendrán una buena experiencia de usuario.
Si tuviera que hacerlo de nuevo, creo que probaría el método vainilla. Construir completamente sin ayudantes como componentes Angular, Material o UI. Intentaría construir desde cero en HTML, CSS y JavaScript y vería si no perdía la conveniencia como pensé que lo haría.
Conclusión
Puede acceder al código final de Angular aquí en GitHub.
Esta fue una descripción general de algunas de las principales decisiones que tomé al desarrollar mi proyecto. Por supuesto, hay más en la construcción de un front-end de acortador de URL. Pero, para empezar, estos componentes de la interfaz de usuario hicieron que el proceso de creación fuera cómodo. Hicieron que el formulario del editor de enlaces respondiera y puede ser de uso similar para usted en sus proyectos (no necesariamente un acortador de URL).
Hay muchos otros componentes de la interfaz de usuario de diferentes bibliotecas que puede usar para cualquier proyecto similar, pero como en mi caso, si la comodidad es un factor decisivo, tomará la decisión correcta de una solución que sea adecuada para la interfaz de usuario.
En última instancia, lo que dio forma a mis decisiones fue entender lo que requería mi proyecto, el conocimiento de las herramientas que había usado en proyectos anteriores y las expectativas con las limitaciones de tiempo. Mis experiencias pasadas —éxitos y errores— también ayudaron a guiarme.
¡Salud!
Deja una respuesta