Spanish (Español) translation by Elías Nicolás (you can also view the original English article)
En
este primer artículo de una nueva serie sobre Asset Pipeline in Rails,
me gustaría analizar algunos conceptos de alto nivel que son útiles para
entender completamente lo que ofrece Asset Pipeline y lo que hace bajo
el capó. Las principales cosas que administra son la concatenación, la
minificación y el preprocesamiento de los activos. Como principiante,
necesita familiarizarse con estos conceptos lo antes
posible.
Temas
- Asset Pipeline?
- Organización
- Concatenación y Compresión?
- Idiomas de alto nivel
Asset Pipeline?
El Asset Pipeline no es exactamente una novedad para las personas en el negocio, pero para los principiantes puede ser un poco difícil de entender rápidamente. Los desarrolladores no gastan exactamente una tonelada de tiempo en productos de front-end, especialmente cuando comienzan. Están ocupados con muchas partes móviles que no tienen nada que ver con HTML, CSS o los bits JS a menudo criticados.
El Asset Pipeline puede ayudar administrando la concatenación, la minificación y el preprocesamiento de activos, por ejemplo, activos escritos en lenguajes de alto nivel como CoffeeScript o Sass.
Este es un paso importante en el proceso de compilación de las aplicaciones de Rails. El Asset Pipeline puede darle un impulso no solo en calidad y velocidad, sino también en comodidad. Tener que configurar su propia herramienta de compilación personalizada podría brindarle algunas opciones más para ajustar sus necesidades, pero viene con una sobrecarga que puede consumir mucho tiempo para los principiantes, incluso puede ser intimidante. En este sentido, podríamos hablar de Asset Pipeline como una solución que fomenta la conveniencia sobre la configuración.
La otra cosa que no debe subestimarse es la organización. El pipeline ofrece un marco sólido para colocar sus activos. En proyectos más pequeños esto puede no parecer tan importante, claro, pero proyectos más grandes pueden no recuperarse fácilmente de ir en la dirección incorrecta en temas como este. Este podría no ser el ejemplo más común en el mundo, pero imagine un proyecto como Facebook o Twitter teniendo una mala organización para sus activos de CSS y JS. No es difícil imaginar que esto engendraría problemas y que a las personas que tienen que trabajar y construir sobre esa base no les sería fácil amar sus trabajos.
Al igual que con muchas cosas en Rails, existe un enfoque convencional de cómo manejar los activos. Esto facilita la incorporación de nuevas personas y evitar que los desarrolladores y diseñadores estén tan obsesionados con traer su propia masa a la fiesta.
Cuando te unes a un equipo nuevo, quieres ser capaz de ponerte al día rápidamente y comenzar a ejecutar. Necesitar descubrir la salsa especial de cómo otras personas organizaron sus activos no es exactamente útil con eso. En casos extremos, esto puede incluso considerarse un desperdicio y puede quemar dinero innecesariamente. Pero no nos pongamos demasiado dramáticos aquí.
Así
que este artículo es para los principiantes entre ustedes, y les
recomiendo echarle un vistazo a la tubería de inmediato y obtener un
buen control sobre este tema, incluso si no esperan trabajar en el
marcado o en las cosas de la parte delantera mucho en el futuro. Es un
aspecto esencial en Rails y no es tan importante. Además, los miembros
de tu equipo, especialmente los diseñadores que
pasan la mitad de su vida en estos directorios, pondrán menos cosas
divertidas en tu café si tienes algo en común que no entre en
conflicto.
Organización
Tienes tres opciones para colocar tus activos. Estas divisiones son más lógicas. No representan restricciones o limitaciones técnicas. Puede colocar activos en cualquiera de ellos y ver los mismos resultados. Pero para una organización más inteligente, debe tener una buena razón para colocar el contenido en su lugar.
app/assets
app/assets/ ├── images ├── javascripts │ └── application.js └── stylesheets └── application.css
La
carpeta app/assets
es para activos que son específicamente para esta
aplicación: imágenes, archivos JS y CSS que están hechos a medida para
un proyecto en particular.
lib/assets
lib/assets/
La carpeta
lib/assets
, por otro lado, es el hogar de su propio código que puede
reutilizar de proyecto en proyecto, cosas que usted mismo podría haber
extraído y desea llevar de un proyecto al siguiente, específicamente,
activos que usted puede compartir entre aplicaciones.
vendor/assets
vendor/assets/ ├── javascripts └── stylesheets
vendor/assets
es otro paso hacia afuera. Es el hogar de activos que reutilizó de otras fuentes externas:
complementos y marcos de terceros.
Estas son las tres ubicaciones en las
que Piñones buscará activos. Dentro de los directorios anteriores, se
espera que coloque sus activos en las carpetas /images
, /stylesheets
y
/javascripts
. Pero esto es más una cosa convencional; cualquier activo
dentro de las carpetas */assets
se atravesará. También puede agregar
subdirectorios según sea necesario. Rails no se quejará y precompilará
sus archivos de todos modos.
Hay una manera fácil de echar un vistazo a
la ruta de búsqueda de la cartera de activos. Cuando enciende una
consola de Rails con rails console
, puede inspeccionarla con el
siguiente comando:
Terminal
Rails.application.config.assets.paths
Lo que obtendrá devuelto es una matriz con todos los directorios de activos disponibles y encontrados por Sprockets, también conocida como la ruta de búsqueda.
=> ["/Users/example-user/projects/test-app/app/assets/images", "/Users/example-user/projects/test-app/app/assets/javascripts", "/Users/example-user/projects/test-app/app/assets/stylesheets", "/Users/example-user/projects/test-app/vendor/assets/javascripts", "/Users/example-user/projects/test-app/vendor/assets/stylesheets", "/usr/local/lib/ruby/gems/2.3.0/gems/turbolinks-2.5.3/lib/assets/javascripts", "/usr/local/lib/ruby/gems/2.3.0/gems/jquery-rails-4.1.1/vendor/assets/javascripts", "/usr/local/lib/ruby/gems/2.3.0/gems/coffee-rails-4.1.1/lib/assets/javascripts"]
Lo bueno de todo esto es fácil de perder. Es el aspecto de tener convenciones. Eso significa que los desarrolladores, y también los diseñadores, en realidad, pueden tener ciertas expectativas sobre dónde buscar los archivos y dónde ubicarlos. Eso puede ser un gran ahorro de tiempo (la voz de Trump). Cuando alguien nuevo se une a un proyecto, tiene una buena idea de cómo navegar un proyecto de inmediato.
Eso no solo es conveniente, sino que también puede evitar ideas cuestionables o reinventar la rueda todo el tiempo. Sí, la convención sobre la configuración puede sonar un poco aburrida a veces, pero no obstante es algo poderoso. Nos mantiene enfocados en lo que importa: el trabajo en sí mismo y la buena colaboración en equipo.
Sin embargo, los caminos de
los activos mencionados no están escritos en piedra. Puede agregar rutas
personalizadas también. Abra config/application.rb
y agregue rutas
personalizadas que desee que Rails reconozca. Echemos un vistazo a cómo
agregaríamos una carpeta personalizada custom_folder
.
config.application.rb
module TestApp class Application < Rails::Application config.assets.paths << Rails.root.join("custom_folder") end end
Cuando
vuelva a comprobar la ruta de búsqueda, encontrará que su carpeta
personalizada forma parte de la ruta de búsqueda de la canalización de
activos. Por cierto, ahora será el último objeto colocado en la matriz:
Terminal
Rails.application.config.assets.paths
Salida
["/Users/example-user/projects/test-app/app/assets/images", "/Users/example-user/projects/test-app/app/assets/javascripts", "/Users/example-user/projects/test-app/app/assets/stylesheets", "/Users/example-user/projects/test-app/vendor/assets/javascripts", "/Users/example-user/projects/test-app/vendor/assets/stylesheets", "/usr/local/lib/ruby/gems/2.3.0/gems/turbolinks-2.5.3/lib/assets/javascripts", "/usr/local/lib/ruby/gems/2.3.0/gems/jquery-rails-4.1.1/vendor/assets/javascripts", "/usr/local/lib/ruby/gems/2.3.0/gems/coffee-rails-4.1.1/lib/assets/javascripts", #<Pathname:/Users/example-user/projects/test-app/custom_folder>]
Concatenación y Compresión?
¿Por qué necesitamos esas cosas? Para resumir, quieres que tus aplicaciones se carguen más rápido. ¡Punto! Cualquier cosa que ayude con eso es bienvenida. Por supuesto, puede escapar sin optimizarlo, pero tiene demasiadas ventajas que simplemente no puede ignorar. Comprimir los tamaños de los archivos y concatenar múltiples archivos de activos en un único archivo "maestro" que un cliente descarga como un navegador tampoco es mucho trabajo. En general, es manejado por la tubería de todos modos.
Reducir el número de solicitudes de páginas de renderizado es muy eficaz para acelerar las cosas. En lugar de tener quizás 10, 20, 50 o cualquier cantidad de solicitudes antes de que el navegador termine de obtener sus activos, es posible que solo tenga uno para cada activo de CSS y JS. Hoy es algo bueno tener, pero en algún momento esto fue un cambio de juego. Este tipo de mejoras en el desarrollo web no debe descuidarse porque estamos lidiando con milisegundos como una unidad.
Muchas solicitudes pueden sumarse sustancialmente. Y, después de todo, la experiencia del usuario es lo más importante para proyectos exitosos. Hacer que los usuarios esperen solo un poco más antes de que puedan ver el contenido presentado en su página puede ser un gran obstáculo. La paciencia no es algo que podamos esperar de nuestros usuarios.
La minificación es genial porque se deshace de cosas innecesarias en sus archivos, espacios en blanco y comentarios, básicamente. Estos archivos comprimidos no están hechos con la legibilidad humana en mente. Son puramente para el consumo de la máquina. Los archivos terminarán siendo un poco crípticos y difíciles de leer, aunque siguen siendo todos códigos válidos de CSS y JS, solo que sin exceso de espacio en blanco para que sea legible y comprensible para los humanos.
Sin embargo, la compresión JS es un poco más complicada. Los navegadores web no necesitan ese formato. Eso nos permite optimizar estos activos. El tema clave de esta sección es que una cantidad reducida de solicitudes y tamaños de archivo minimizados aceleran las cosas y deberían estar en su bolsa de trucos. Rails le ofrece esta funcionalidad de forma inmediata sin ninguna configuración adicional.
Lenguajes de alto nivel
Es posible que ya hayas oído hablar de ellos, pero como principiante, es posible que no estés al tanto de por qué deberías aprender otro idioma, especialmente si todavía estás ocupado aprendiendo a escribir HTML y CSS clásicos. Estos idiomas se crearon para hacer frente a las deficiencias que los desarrolladores querían resolver. En su mayoría, abordan problemas que los desarrolladores no querían abordar a diario. El desarrollo clásico impulsado por la pereza, supongo.
Los "lenguajes de alto nivel" parecen más sofisticados de lo que podrían ser, sin embargo, son radicales. Estamos hablando de Sass, CoffeeScript, Haml, Slim, Jade y cosas por el estilo. Estos idiomas nos permiten escribir en una sintaxis (principalmente) fácil de usar que puede ser más conveniente y eficiente para trabajar. Todos ellos deben ser precompilados durante un proceso de compilación.
Menciono esto porque esto puede suceder detrás de las escenas sin que te des cuenta. Eso significa que toma estos activos y los transforma en CSS, HTML y JS antes de que se implementen y el navegador los pueda representar.
Sass
Sass significa "Hojas de estilo sintácticamente impresionantes" y es mucho más potente que el CSS puro. Nos permite escribir hojas de estilo más inteligentes que tienen algunas herramientas de programación incorporadas. ¿De qué estamos hablando aquí, exactamente? Puede declarar variables, reglas de anidar, escribir funciones, crear mezclas, importar fácilmente parciales, y muchas otras cosas que los programadores querían tener disponibles mientras jugaba con estilos.
Se ha convertido en una herramienta bastante rica por ahora y es excelente para organizar hojas de estilo; para proyectos grandes, incluso lo llamaría esencial. En estos días, no estoy seguro de si no me mantendría alejado de una aplicación grande que no está usando una herramienta como Sass, o cualquier estructura no relacionada con Ruby que tenga que ofrecer al respecto.
Para sus inquietudes actuales, hay dos versiones de sintaxis de
Sass que debe conocer. La versión Sassy CSS, también conocida como
SCSS, es la versión más ampliamente adoptada. Se
mantiene más cercano al CSS simple pero ofrece todas las extensiones de
fantasía. A los desarrolladores y diseñadores les encanta jugar con
hojas de estilo. Utiliza la extensión de archivo .scss
y se ve así:
SCSS
#main p { color: #00ff00; width: 97%; .redbox { background-color: #ff0000; color: #000000; } }
Visualmente, no es tan diferente de CSS, por eso es la opción más popular, especialmente entre los diseñadores, creo. Uno de los aspectos realmente geniales y útiles de SCSS, y Sass en
general, es el aspecto de anidación. Esta es una estrategia efectiva
para crear estilos legibles pero también reduce mucho las declaraciones
repetitivas.
SCSS
#main { color: blue; font-size: 0.3em; a { font: { weight: bold; family: serif; } &:hover { background-color: #eee; } } }
Compare el ejemplo anterior con la respectiva versión de CSS. Parece agradable adelgazar estos estilos con la anidación, ¿no?
CSS
#main { color: blue; font-size: 0.3em; } #main a { font-weight: bold; font-family: serif; } #main a:hover { background-color: #eee; }
La sintaxis de Sass con sangría tiene la extensión de archivo .sass
. Éste le permite evitar lidiar con todas estas llaves tontas y puntos y
comas que los desarrolladores perezosos prefieren evitar.
¿Como hace eso? Sin los corchetes, Sass utiliza indentación, espacio en blanco en
esencia, para separar sus propiedades. Es bastante raro y se ve muy bien
también. Para ver las diferencias, te mostraré ambas versiones una al
lado de la otra.
.sass
#main color: blue font-size: 0.3em a font: weight: bold family: serif &:hover background-color: #eee
.scss
#main { color: blue; font-size: 0.3em; a { font: { weight: bold; family: serif; } &:hover { background-color: #eee; } } }
Muy bonito y compacto, ¿eh? Pero ambas versiones necesitan procesamiento antes de convertirse en CSS válido que los navegadores puedan comprender. El Asset Pipeline se ocupa de eso por usted. Si aciertas en los navegadores con algo como Sass, no tendrían idea de lo que está pasando.
Yo personalmente prefiero la sintaxis con sangría. Esta sintaxis Sass sensible al espacio en blanco es menos popular que la sintaxis SCSS, lo que podría no convertirla en la opción ideal para proyectos que no sean los personales. Probablemente sea una buena idea elegir la opción más popular entre su equipo, especialmente con los diseñadores involucrados. Implicar la moda en el espacio en blanco con personas que han pasado años domesticando todas las llaves y los puntos y comas parece una mala idea.
Ambas versiones tienen los mismos trucos de programación en sus mangas. Son excelentes para hacer que el proceso de escribir estilos sea mucho más agradable y efectivo. Para nosotros es una suerte que Rails y Asset Pipeline hagan que trabajar con cualquiera de estos sea tan fácil, prácticamente fuera de la caja.
Slim & Haml
Se pueden hacer argumentos similares sobre los beneficios de usar algo como Slim y Haml. Son bastante útiles para crear marcas más compactas. Se compilará en HTML válido, pero los archivos con los que trabaja son mucho más reducidos.
Puede ahorrarse la molestia de escribir etiquetas de cierre y utilizar abreviaturas geniales para nombres de etiquetas y cosas por el estilo. Estas ráfagas más cortas de marcado son más fáciles de leer y repasar. Personalmente, nunca he sido un gran admirador de Haml, pero Slim no solo es elegante y conveniente, también es muy inteligente. Para las personas que les gusta la sintaxis indecente de Sass, definitivamente recomendaría jugar con ella. Echemos un vistazo rápido:
Slim
#content .left.column h2 Welcome to our site! p= print_information .right.column = render :partial => "sidebar"
Haml
#content .left.column %h2 Welcome to our site! %p= print_information .right.column = render :partial => "sidebar"
Ambos dan como resultado el siguiente HTML mejorado con ERB en Rails:
<div id="content"> <div class="left column"> <h2>Welcome to our site!</h2> <p> <%= print_information %> </p> </div> <div class="right column"> <%= render :partial => "sidebar" %> </div> </div>
En
la superficie, las diferencias no son tan grandes, pero nunca entiendo
por qué Haml quiere que escriba todo este %
adicional para anexar las
etiquetas. Slim encontró una solución que se deshizo de estos, ¡y por eso saludo al
equipo! No es un gran dolor, pero es molesto, sin embargo. Las otras
diferencias están bajo el capó y no están dentro del alcance de esta
pieza hoy. Solo quería despertar tu apetito.
Como puede ver, ambos preprocesadores reducen significativamente la cantidad que necesita escribir. Sí, necesitas aprender otro idioma, y al principio es un poco raro. Al mismo tiempo, creo que la eliminación de todo ese desorden merece la pena. Además, una vez que sepa cómo escribir HTML con ERB, podrá recoger cualquiera de estos preprocesadores con bastante rapidez. Nada de ciencia espacial: lo mismo ocurre con Sass, por cierto.
En caso de que estés interesado, hay dos gemas útiles para usar cualquiera de ellos en Rails. Hazte un favor y échale un vistazo cuando te canses de escribir todas estas tediosas etiquetas de apertura y cierre.
gem "slim-rails" gem "haml-rails"
CoffeeScript
CoffeeScript es un lenguaje de programación como cualquier otro, pero tiene ese sabor Ruby para escribir tu JavaScript. A través del preprocesamiento, se compila en JavaScript simple y antiguo
que los navegadores pueden manejar. El breve argumento para trabajar
con CoffeeScript fue que ayudó a superar algunas deficiencias que JS
estaba teniendo. La documentación dice que tiene como objetivo exponer
las "buenas partes de JavaScript de una manera simple". ¡Lo
suficientemente justo! Echemos un vistazo rápido a un pequeño ejemplo y
veamos con qué estamos tratando:
JavaScript
$( document ).ready(function(){ var $on = 'section'; $($on).css({ 'background':'none', 'border':'none', 'box-shadow':'none' }); });
En CoffeeScript, este chico se vería así:
CoffeeScript
$(document).ready -> $on = 'section' $($on).css 'background': 'none' 'border': 'none' 'box-shadow': 'none' return
Lee un poco mejor sin todos los rizos y punto y coma, ¿no? CoffeeScript intenta ocuparse de algunos de los molestos bits de JavaScript, le permite escribir menos, hace que el código sea un poco más legible, ofrece una sintaxis más amigable y trata de manera más agradable las escritura de clases. Definir clases fue una gran ventaja por un tiempo, especialmente para las personas que venían de Ruby que no eran muy aficionadas a tratar con JavaScript puro. CoffeeScript tomó un enfoque similar al de Ruby y te da una buena pieza de azúcar sintáctica. Las clases se ven así, por ejemplo:
Class
class Agent constructor: (@firstName, @lastName) -> name: -> "#{@first_name} #{@last_name}" introduction: (name) -> "My name is #{@last_name}, #{name}"
Este lenguaje fue bastante popular en la tierra de Ruby por un tiempo. No estoy seguro de cómo son las tasas de adopción en estos días, pero CoffeeScript es el sabor predeterminado de JS en Rails. Con ES6, JavaScript ahora también es compatible con las clases, una gran razón para no usar CoffeeScript y jugar con JS en su lugar. Creo que CoffeeScript sigue siendo más agradable, pero muchas de las razones menos cosméticas para usarlo han sido abordadas con ES6 en estos días. Creo que sigue siendo una buena razón para intentarlo, pero eso no es por lo que viniste aquí. Solo quería darle otro aperitivo y darle un poco de contexto acerca de por qué Asset Pipeline le permite trabajar en CoffeeScript de fábrica.
Pensamientos finales
El Asset Pipeline ha demostrado mucho más de lo que esperaba cuando se presentó. En ese momento, realmente causó sensación y estaba causando un gran dolor a los desarrolladores. Todavía lo hace, por supuesto, y se ha establecido como una herramienta sin fricción y sin esfuerzo que mejora la calidad de sus aplicaciones.
Lo que más me gusta de él es la poca dificultad que implica hacer que funcione. No me malinterpreten, herramientas como Gulp y Grunt son impresionantes también. Las opciones de personalización son muchas. Simplemente no puedo evitar la sensación de comodidad que Rails me da cuando no tengo que lidiar con ninguna configuración antes de comenzar. Las convenciones pueden ser poderosas, especialmente el suero, ya que resultan en algo sin problemas y sin problemas.
Subscribe below and we’ll send you a weekly email summary of all new Code tutorials. Never miss out on learning about the next big thing.
Update me weeklyEnvato Tuts+ tutorials are translated into other languages by our community members—you can be involved too!
Translate this post