9

Después de implementar mi aplicación actualizada Rails 2.3.x -> 3.1 (rc4) en nuestro entorno de prueba esta tarde, todas nuestras hojas de estilo y archivos de JavaScript devolvieron errores 404. Añadimos los activos de rake: tarea de precompilación a nuestro script de post-implementación y nos tomó un tiempo determinar por qué la carpeta de activos no tenía los archivos precompilados que esperábamos.Canalización de activos de Rails 3.1: archivos perdidos de público/activos: ¿por qué no es este el valor predeterminado?

Al final, los archivos no se estaban compilando porque aparentemente solo se procesan por defecto application.css y application.js (+ archivos JS/CSS).

necesitamos cambiar el valor de configuración de la siguiente manera siguiente:

config.assets.precompile += %w(*.js *.css) 

Pregunta: ¿Por qué no es este el defecto?

Hubiera esperado que todo lo que no era necesario procesar como archivo de manifiesto simplemente se copiara en public/assets. Mucho de lo que he leído en el inventario de activos es esencialmente "pegar sus activos en la aplicación/activos, configurar los archivos de manifiesto, y simplemente debería funcionar". Dado que los activos: la tarea de precompilación no escupió ninguna información sobre lo que estaba haciendo, tomó un tiempo determinar que simplemente no estaba mirando los archivos que pensábamos que sería.

¿Hay alguna razón por la que este no sea un buen valor para la configuración de precompilación?

Gracias!

Respuesta

9

La idea es tener todos sus JavaScript y CSS siempre cargados de una vez, en lugar de cargar partes y piezas a medida que avanza. De esa manera siempre tendrá el "mundo" cargado y listo para trabajar, en lugar de tener que incluir un montón de archivos individuales aquí y allá.

Se trata de una carga 'inicial' más grande, pero luego el navegador debe seguir cargando todo el javascript de la memoria caché. Por lo tanto, la velocidad percibida del sitio debería acelerarse debido a que todo está en caché y listo para funcionar después de la primera solicitud.

Esta fue una decisión polémica para incluir en Rails, pero también incluye CoffeeScript de manera predeterminada. Rails siempre ha sido un marco obstinado de esa manera.

+0

Gracias, Chris, por la respuesta. Entiendo que tiene sentido reducir las solicitudes HTTP de eficiencia, pero creo que la mayoría de las aplicaciones tienen su CSS segmentado en al menos hojas de estilo internas/externas y archivos modulares de JavaScript. Simplemente parece un cambio real de la forma en que el resto del framework de Rails se ocupa de las cosas, pero basado en los valores predeterminados, ciertamente parece que debe haber sido el pensamiento. – shedd

+0

Bueno, uno definitivamente querría cortar sus archivos en los modulares. La idea es que la aplicación.js y la aplicación.css tienen "includes" que incorporan todos los javascript y css específicos en esos directorios (si busca en esos archivos, encontrará una directiva 'require_tree.', Que ingresa todo en ese directorio y todos sus hijos). –

+0

La mayoría de las aplicaciones de Rails no tienen CSS segmentado en diferentes hojas de estilo, al menos tal como se entregan al cliente. Los CSS de fuente separada (y JS) se compilan en un agregado application.css (o .js) por la canalización de activos. Aún así, tiendo a estar de acuerdo contigo sobre los valores predeterminados de Rails, si (* .js * .css) fuera el predeterminado, aún así funcionaría bien o la forma "sugerida" de hacerlo, pero también funcionaría. lo que estabas tratando de hacer Creo que las versiones anteriores de Rails realmente funcionaron como sugieres, pero lo cambiaron más recientemente, tal vez por buenas razones por las que no estamos pensando. – jrochkind

0

la nueva canalización basada en piñones compila todos los archivos en/asssets/stylesheets y/assets/javascripts se compilan en application.css y application.js, respectivamente, de manera predeterminada.

En sus puntos de vista, solo necesita vincular los archivos de la aplicación, los piñones manejan el resto.

Actualización: Bueno, no tiene que hacer todo en un solo archivo ... Podría tener un shared.js, secure.js y public.js y hacer que cada uno incluya las piezas que necesita. ..

pensar en ellos archivos no como JavaScript, pero los archivos de manifiesto que establecen grupos de archivos javascript que luego se puede incluir como un grupo con un solo javascript_include_tag. Si bien el valor predeterminado es incluir todo en la carpeta en un único archivo, siempre puede elegir y elegir qué incluir y qué no.

La tarea 'precompilar' simplemente ejecuta esos archivos de manifiesto y compila los archivos múltiples en uno, mientras se procesa el preprocesamiento y el sass o el script de café.

+0

Gracias, Colin. Sí, me di cuenta de eso, pero la pregunta estaba sondeando un poco más allá. – shedd

+0

bien, actualicé la publicación para obtener más información – colinross

Cuestiones relacionadas