Comenzando con la tubería de activos, Parte 1

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.