ruby on rails - rails - ¿Qué hace exactamente la configuración "config.assets.debug"?
crud with ruby on rails (2)
He comenzado el desarrollo de aplicaciones de rieles simples. Después de varias horas de trabajo, tengo avisos de que de alguna manera el css eliminado todavía se aplica a las páginas web.
Para solucionar el problema ejecuté las siguientes acciones varias veces:
- detener / iniciar servidor
- usar el servidor de rieles
- usar el servidor torquebox
- borrar el caché del navegador
pero nada cambia. Fue muy extraño: se aplicaron las nuevas definiciones de css, pero las que he eliminado todavía estaban allí. Entonces, me rendí y decidí crear un nuevo proyecto.
He configurado el nuevo proyecto (su andamio es el mismo que el primero) y cuando abro una de las vistas, también se aplicaron los estilos del proyecto anterior. He decidido volver a buscar en http://guides.rubyonrails.org/asset_pipeline.html y descubrir esa configuración
#Expands the lines which load the assets
config.assets.debug = false
Resuelve el problema. Pero, ¿qué está haciendo exactamente esta opción? ¿Por qué los antiguos proyectos css se aplicaron cuando esto era cierto?
El efecto de esta opción está bien descrito en esta publicación , pero la resumiré aquí también. El valor de cambiar config.assets.debug reside en un compromiso entre el tiempo de carga de la página en desarrollo y la facilidad de depuración.
Básicamente:
config.assets.debug = true : los activos se sirven individualmente, organizados tal como los ve en desarrollo. Los lenguajes preprocesados como SASS o CoffeeScript seguirán apareciendo como sus lenguajes de destino (es decir, CSS y JS, respectivamente).
config.assets.debug = false : los activos se agrupan en archivos como application.css y application.js . Es probable que los seguimientos de la pila de errores ya no tengan el número de línea correcto y es más difícil asignarlos a su código original.
Si accede a esta página web, existe la posibilidad de que esté aquí porque está utilizando el Oleoducto de activos de Rails y realizó cambios en uno de los archivos javascript y volvió a cargar la página, y el cambio no se refleja cuando busca en la pestaña Fuentes en cromo.
Como se indicó anteriormente, config.assets.debug = false solicita a la gema Sprockets que config.assets.debug = false todos los archivos javascript y css individuales en un application.js y application.css respectivamente. Además, Sprockets ejecuta los preprocesadores SASS y CoffeeScript (si no usó --skip-coffee) en todos los archivos asociados para generar archivos css y javascript que el navegador pueda entender.
Una nota importante es la siguiente. Ruby Guides dice esto acerca de debug = false:
Los activos se almacenan en caché en la primera solicitud después de que se inicie el servidor. Si alguno de los archivos en el manifiesto ha cambiado entre solicitudes, el servidor responde con un nuevo archivo compilado.
Esto significa que si no cambia los archivos css o javascript entre las solicitudes, se utilizará un caché. Tan pronto como cambia un archivo, la memoria caché se invalida y se crea una nueva memoria caché para las solicitudes posteriores.
En consecuencia, si realizó cambios en un archivo javascript y el cambio no se refleja en la recarga de la página, no tiene nada que ver con esta opción config.assets.debug .
Hay esta otra opción llamada config.action_controller.perform_caching .
Pero de forma predeterminada, esta opción por defecto es falsa en el desarrollo. Es decir, de forma predeterminada, el almacenamiento en caché solo está habilitado en su entorno de producción. Y en las versiones actuales, Rails solo se envía con Fragment Caching por defecto. Tienes que instalar gemas separadas para el almacenamiento en caché de página y acción.
El almacenamiento en caché de fragmentos permite que un fragmento de la lógica de vista se incluya en un bloque de caché y se sirva fuera del almacén de caché cuando llegue la siguiente solicitud. Pero, nuevamente, los fragmentos de caché también caducarán cuando el fragmento de vista cambie la vista cambia).
Entonces, la pregunta sigue siendo: ¿por qué no se refleja el cambio de tu javascript? La respuesta es Google Chrome, el navegador en sí mismo, es el almacenamiento en caché de la página a pesar de la configuración de Rails. Para eliminar el caché, cierre la pestaña actual, abra una nueva pestaña y visite el sitio nuevamente.