Haml: Solicitud de función: carpeta de importación

Soy escéptico sobre la utilidad de esto. No creo que tener que enumerar manualmente todos los archivos relevantes sea realmente tan oneroso. Además, parece que podría conducir al peligro de no obtener errores de compilación reales cuando un archivo que espera que exista no existe. En cambio, los estilos desaparecen aparentemente de forma arbitraria.

Entiendo su argumento, sin embargo, no creo que esté viendo el otro tipo de situación que se necesita. Actualmente tengo una carpeta que tendrá más de 60 archivos Sass. Sin la capacidad de @importar una carpeta, necesito mantener un archivo que importe cada archivo individualmente.

Hay muchos problemas al incluir cada archivo individualmente. En primer lugar, si olvida incluir un archivo, no recibirá una advertencia. A continuación, si tiene un equipo de desarrolladores trabajando en Sass, cada uno de ellos debe recordar importar el archivo manualmente después de crearlo en la carpeta. Depender de que la gente haga lo correcto se romperá eventualmente.

Además, tenemos prioridad en que importar una carpeta es "algo bueno". La declaración de importación de Java le permite importar paquetes completos o clases específicas de esos paquetes.

El orden de las importaciones es importante en el caso general porque los selectores del mismo peso se resuelven de acuerdo con el orden del documento. Globbing significa que agregar un archivo puede cambiar inesperadamente el orden de resolución global de los selectores.

Tales problemas de ordenación no están presentes en el código y donde están (como ruby) no existe tal característica.

Me interesaría ver si hay una manera de hacer esto en Sass sin un cambio en el mecanismo de importación del núcleo de Sass. Esto permitiría a los marcos y a las personas que utilizan sass desarrollar su propio sistema de globbing como mejor les parezca. Por ejemplo:

<strong i="8">@import</strong> file-list("foo/*.sass");

Solíamos tener una lógica de análisis especial para @import que hubiera impedido esto, pero ya no la tenemos.

El problema de permitir importaciones verdaderamente dinámicas (como las funciones via) es que entonces la estructura de dependencia de un documento se vuelve imposible de descifrar dinámicamente. Esto significa que el almacenamiento en caché y la compilación selectiva se vuelven mucho menos útiles.

Para problemas de orden, siempre podríamos ordenar los archivos alfabéticamente o algo para llegar a un orden determinista (aunque arbitrario). Sin embargo, esto todavía presenta el problema de que el pedido podría cambiar e interrumpir la funcionalidad si cambia el nombre de un archivo.

Presumiblemente, un enfoque de este tipo a través del globbing implicaría el uso de selectores anidados para evitar tales problemas.

En mi opinión, importar un árbol de directorios completo de archivos tiene solo una utilidad marginal sobre el enfoque de importación explícita y alienta al usuario a considerar los problemas de precedencia. Si agregamos una característica de este tipo, me gustaría que tuviera un propósito más general que solo a nivel de directorio.

Por último, creo que tiene razón en que la introducción de un glob que estaba fuera del gráfico de dependencia y aparece como importaciones únicas en el motor sass significa que es más difícil invalidar archivos cuando aparecen nuevas dependencias que coinciden con el glob.

Estoy de acuerdo en que la importación de una carpeta daría lugar a un orden ambiguo de importación de archivos. Sin embargo, eso debería depender del usuario para decidir si es lo correcto para ellos. Se ajustará a algunas situaciones pero no a otras. Definitivamente es posible imaginar un sistema en el que el contenido de una carpeta no se dirija a los mismos elementos (el mío no).

Al igual que la importación de archivos específicos funciona. se adapta a algunas situaciones pero no a otras.

La elección debe depender del desarrollador.

Es demasiado fácil para un usuario tener hojas de estilo que dependen del pedido y no las sabe. Cualquier cosa podría desencadenar un reordenamiento y crear errores de diseño que serían muy difíciles de rastrear. Y no estaría lo suficientemente claro que la importación de un directorio dejaría a alguien abierto a tales problemas. Sin embargo, ordenar a través del nombre de archivo probablemente sería una solución suficientemente buena para esto, por lo que no es un impedimento serio.

La extensión que consideraría permitiría globs de archivos estándar, probablemente los admitidos por Dir.glob . Esto podría resolverse en tiempo de compilación y proporcionaría un grado razonable de poder.

Sin embargo, todavía estoy un poco convencido en cuanto a la utilidad.

Es importante tener en cuenta que los pedidos a través de Dir.glob dependen del sistema de archivos y pueden cambiar entre plataformas; de hecho, esta diferencia entre Mac y Linux me ha mordido. Entonces, si terminamos implementando una característica de este tipo, es importante que clasifiquemos la lista de acuerdo con un enfoque bien documentado y fácil de entender (por ejemplo, clasificación reducida)

También me estoy apoyando un poco en esta función. El enfoque de importación que utiliza la brújula no ha sido realmente una carga de mantenimiento. Sin embargo, sin duda es una característica comúnmente solicitada. Creo que ha aparecido en la lista de correo y en Twitter unas 4 o 5 veces.

Ciertamente ordenaremos los archivos de manera determinista de alguna manera. La clasificación mejorada frente a la categoría reducida es una pregunta interesante ... probablemente deberíamos hacer la clasificación reducida con upcased como un desempate (ya que permitirá vínculos en sistemas de archivos que distinguen entre mayúsculas y minúsculas).

Estoy de acuerdo. Estoy en contra de poder pasar un parámetro directamente a Dir.glob. Eso realmente parece una característica innecesaria. ¿Pueden pensar en un escenario en el que sea ventajoso tener ese grado de control?

Parece que las siguientes dos opciones deberían ser suficientes:
-Cherry recoge archivos usando @import
-Importar un directorio completo usando @import folder_name

Además, creo que el orden alfabético funcionará bien. Solo necesitamos asegurarnos de que esté documentado.

Importar directorios a través de <strong i="5">@import</strong> dir es demasiado ambiguo con la importación de archivos individuales. Definitivamente deberíamos agregar al menos * globs.

Sin embargo, todavía no estoy convencido.

es útil si tiene diferentes "estilos" para una página. ejemplo:
genérico / (xx archivos sass aquí)
style1 / (xx archivos sass aquí que agregan / sobrescriben estilos a los que están en genérico)
style2 / (xx archivos sass aquí que agregan / sobrescriben estilos a los que están en genérico)
style1.sass (simplemente: @import generic / _, style1 / _)
style2.sass (simplemente: @import generic / _, style2 / _)

¿Por qué no podría simplemente tener _generic.sass que importa todo en el directorio genérico?

No creo que se trate de lo que se puede o no se puede hacer tanto como deberían. En última instancia, el orden de las hojas de estilo es importante y, por lo tanto, quiero que el usuario lo piense en ello. Es cierto que las bibliotecas que solo definen mixins y variables son independientes del orden, al igual que las hojas de estilo con ámbito, pero me preocupa proporcionar una capacidad general que se utilizará incorrectamente.

¿Definir "hojas de estilo con ámbito"?

Hojas de estilo que anidan la mayoría o todos sus selectores. por ejemplo, body.foo

No se garantiza que sean independientes del orden. Otra hoja de estilo en otro lugar podría definir body.foo ... , o algo más con mayor especificidad.

Entonces realmente no tiene un marco de trabajo porque sus archivos no están separados correctamente.

Hay muchas formas en las que la gente puede estropear su CSS. Podemos proporcionarles esta solución y explicarles cuándo se debe utilizar en lugar de importar archivos individuales.

Al no implementar esta función, les está dando a los desarrolladores que desean implementar hojas de estilo con alcance estas dos opciones:
1) Importe manualmente cada archivo de forma independiente (lo que puede causar errores propios porque no le indica cuándo se perdió un archivo)
2) Implemente un sistema de compilación para agregar dinámicamente estos archivos (lo cual es un desperdicio porque habrá varias personas implementando lo mismo)

Ciertamente, no es el caso de que toda la dependencia del orden de las hojas de estilo con alcance sea el resultado de una mala separación de preocupaciones. Considerar:

body.foo .baz {
  color: blue; }

body.bar .baz {
  color: red; }

Esta hoja de estilo está bien separada, pero aún depende del orden.

En cualquier caso, la idea de que podemos esperar que todos los que utilizan esta función comprendan los riesgos es incorrecta. La única forma de asegurarse de que todo el mundo entienda en qué orden se importarán sus hojas de estilo es especificarlo explícitamente.

En general, las hojas de estilo de ámbito general serán independientes del orden, pero puede darse el caso de que el orden sea importante incluso cuando las preocupaciones se separan correctamente.

Ignorar silenciosamente las importaciones que no se encuentran ya no es un problema en sass3. Solo las importaciones de CSS se ignorarán silenciosamente.

Tengo un archivo sass que importa alrededor de 60 más. Lo cambio cuando se agregan o eliminan archivos y siempre pienso en el pedido cuando lo hago. Nunca me pareció una carga, sino un paso necesario.

Si no se encuentran mis importaciones (siempre especifico .sass para las importaciones), mis pruebas fallan.

Hay una adición: lo más simple posible y no más simple.

Mi instinto me dice que esto simplifica demasiado las cosas y que todo el ahorro de tiempo se pierde con una sesión de depuración. Voto para que dejemos esto a un lado por el momento. Si alguien quiere crear un complemento sass que brinde esta capacidad, estaría muy interesado en ver cómo funciona para esos usuarios.

Creo que el punto de Richard fue que no hay error cuando se crea un parcial pero no se le agrega ninguna importación. Supongo que esto podría aliviarse buscando parciales no utilizados e imprimiendo advertencias para ellos.

Voy a seguir adelante y cerrar esto.

Gah, esto apesta ... tengo una carpeta llamada page_specific / en los activos de mi aplicación rails ...
todos estos deben compilarse en el gran bloque de activos, y cada uno de ellos está completamente envuelto en
cuerpo # página1 {}, cuerpo # página2 {}, etc.

hay cero posibilidades de que dependan del pedido y, francamente, todo este mensaje de "¡¡¡¡No lo usarás! ¡¡¡¡No !!!!!!" la mierda es un insulto.

si un usuario de esta función descubre que el orden es importante, puede importar los archivos en un orden explícito o refactorizar los estilos para que no dependan del orden ... obligar a todos a trabajar manualmente en torno a esta función que falta es basura paternalista>: (

seguramente podemos pensar en una forma de minimizar este pequeño problema de realizar pedidos. el ordenamiento determinista es un comienzo. llamarlo @ import-dir, y la documentación del posible problema de pedido también ayudaría. rails ya proporciona require_tree, y las cosas allí parecen funcionar bien. la única excepción es que los archivos se compilan individualmente, lo que deja caer mis mixins y variables en el suelo. Observo que los mixins son la única parte que se ubicaron como explícitamente independientes del orden, entonces, ¿por qué esto no puede funcionar para sass cuando funciona para todos los demás?

https://github.com/chriseppstein/sass-globbing

@chriseppstein ¡increíble! (y perdón por despotricar como un maníaco todo el mundo)