Haml: Funktionsanfrage: Ordner importieren

Ich bin skeptisch was den Nutzen davon angeht. Ich denke nicht, dass es wirklich so mühsam ist, alle relevanten Dateien manuell auflisten zu müssen. Es scheint auch, dass dies zu der Gefahr führen kann, dass keine tatsächlichen Kompilierungsfehler auftreten, wenn eine Datei, von der Sie erwarten, dass sie nicht existiert. Stattdessen verschwinden Stile scheinbar willkürlich.

Ich verstehe Ihre Argumentation, aber ich glaube nicht, dass Sie die andere Art von Situation sehen, die erforderlich ist. Derzeit habe ich einen Ordner mit mehr als 60 Sass-Dateien. Ohne die Möglichkeit, einen Ordner zu importieren , muss ich eine Datei verwalten, die jede Datei einzeln importiert.

Es gibt viele Probleme, jede Datei einzeln einzuschließen. Erstens erhalten Sie keine Warnung, wenn Sie vergessen, eine Datei einzuschließen. Als nächstes müssen Sie, wenn Sie ein Team von Entwicklern haben, die an Sass arbeiten, daran denken, die Datei nach dem Erstellen im Ordner manuell zu importieren. Abhängig von den Leuten, das Richtige zu tun, wird es irgendwann kaputt gehen.

Außerdem haben wir Vorrang, dass das Importieren eines Ordners eine "gute Sache" ist. Mit der import-Anweisung von Java können Sie ganze Pakete oder bestimmte Klassen dieser Pakete importieren.

Die Reihenfolge der Importe ist im allgemeinen Fall wichtig, da Selektoren mit gleichem Gewicht entsprechend der Dokumentenreihenfolge aufgelöst werden. Globbing bedeutet, dass das Hinzufügen einer Datei die globale Auflösungsreihenfolge von Selektoren unerwartet ändern kann.

Solche Ordnungsprobleme sind im Code nicht vorhanden, und wo sie sind (wie Ruby), gibt es keine solche Funktion.

Mich würde interessieren, ob es eine Möglichkeit gibt, dies in Sass zu tun, ohne den Sass-Kernimportmechanismus zu ändern. Dies würde es Frameworks und Einzelpersonen, die Sass verwenden, ermöglichen, ihr eigenes Globbing-System nach Belieben zu entwickeln. Zum Beispiel:

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

Früher hatten wir eine spezielle Parsing-Logik für @import , die dies verhindert hätte, aber das tun wir nicht mehr.

Das Problem beim Zulassen wirklich dynamischer Importe (z. B. über Funktionen) besteht darin, dass die Abhängigkeitsstruktur eines Dokuments dann nicht mehr dynamisch ermittelt werden kann. Dies bedeutet, dass Caching und selektive Kompilierung viel weniger nützlich sind.

Bei Ordnungsproblemen könnten wir die Dateien immer alphabetisch sortieren oder etwas, um eine deterministische (wenn auch willkürliche) Sortierung zu erhalten. Dies stellt jedoch immer noch das Problem dar, dass sich die Reihenfolge ändern und die Funktionalität stören kann, wenn sich der Name einer Datei ändert.

Vermutlich würde ein solcher Ansatz über Globbing bedeuten, verschachtelte Selektoren zu verwenden, um solche Probleme zu vermeiden.

Meiner Meinung nach hat das Importieren eines ganzen Verzeichnisbaums von Dateien nur einen marginalen Nutzen gegenüber dem expliziten Importansatz und ermutigt den Benutzer, die Prioritätsprobleme zu berücksichtigen. Wenn wir eine solche Funktion hinzufügen, möchte ich, dass sie allgemeiner ist als nur auf Verzeichnisebene.

Schließlich glaube ich, dass Sie Recht haben, dass die Einführung eines Globs, das sich außerhalb des Abhängigkeitsdiagramms befand und als nur einzelne Importe in die Sass-Engine angezeigt wird, bedeutet, dass es schwieriger ist, Dateien für ungültig zu erklären, wenn neue Abhängigkeiten angezeigt werden, die mit dem Glob übereinstimmen.

Ich stimme zu, dass das Importieren eines Ordners zu einer mehrdeutigen Reihenfolge der importierten Dateien führen würde. Das sollte jedoch dem Benutzer überlassen bleiben, ob es das Richtige für ihn ist. Es wird in einige Situationen passen, aber nicht in andere. Es ist definitiv möglich, sich ein System vorzustellen, bei dem der Inhalt eines Ordners nicht auf dieselben Elemente abzielt (meiner nicht).

Genauso wie das Importieren bestimmter Dateien funktioniert. es passt in einige Situationen, aber nicht in andere.

Die Wahl sollte dem Entwickler überlassen bleiben.

Es ist zu einfach für einen Benutzer, Stylesheets zu haben, die von der Reihenfolge abhängig sind und sie nicht kennen. Alles kann eine Neuordnung auslösen und zu Layoutfehlern führen, die sehr schwer aufzuspüren wären. Und es wäre nicht klar genug, dass das Importieren eines Verzeichnisses jemanden für solche Probleme offen lässt. Das Bestellen über den Dateinamen wäre jedoch wahrscheinlich eine ausreichend gute Lösung, daher ist dies kein ernsthaftes Hindernis.

Die Erweiterung, die ich in Betracht ziehen würde, wäre das Zulassen von Standarddateiglobs - wahrscheinlich diejenigen, die von Dir.glob . Dies wäre zur Kompilierzeit lösbar und würde ein angemessenes Maß an Leistung bereitstellen.

Vom Nutzen bin ich allerdings noch weit entfernt.

Es ist wichtig zu bedenken, dass die Bestellung über Dir.glob Dateisystem abhängig ist und sich plattformübergreifend ändern kann -- ich bin tatsächlich von diesem Unterschied zwischen Mac und Linux gebissen worden. Wenn wir also ein solches Feature implementieren, ist es für uns wichtig, die Liste nach einem gut dokumentierten und leicht verständlichen Ansatz zu sortieren (z. B. verkleinerte Sortierung).

Ich lehne mich auch noch ein wenig gegen diese Funktion. Der von Kompass verwendete Importansatz war nicht wirklich ein Wartungsaufwand. Es ist jedoch sicherlich eine häufig nachgefragte Funktion. Ich denke, es wurde jetzt etwa 4 oder 5 Mal auf der Mailingliste und auf Twitter erwähnt.

Wir werden die Dateien sicherlich irgendwie deterministisch ordnen. Upcased vs. Downcased-Sortierung ist eine interessante Frage ... wir sollten wahrscheinlich Downcased mit Upcased als Tiebreaker verwenden (da es Bindungen bei Dateisystemen ermöglicht, bei denen die Groß-/Kleinschreibung beachtet wird).

Ich stimme zu. Ich bin irgendwie dagegen, einen Parameter direkt an Dir.glob übergeben zu können. Das scheint wirklich ein unnötiges Feature zu sein. Können Sie sich ein Szenario vorstellen, in dem es von Vorteil ist, dieses Maß an Kontrolle zu haben?

Es scheint, als ob die folgenden beiden Optionen ausreichen sollten:
-Cherry Pick-Dateien mit @import
-Importieren Sie ein ganzes Verzeichnis mit @import folder_name

Ich denke auch, dass alphabetisch gut funktionieren wird. Wir müssen nur sicherstellen, dass es dokumentiert ist.

Das Importieren von Verzeichnissen über <strong i="5">@import</strong> dir ist beim Importieren einzelner Dateien zu mehrdeutig. Wir sollten auf jeden Fall mindestens * Globs hinzufügen.

Aber immer noch nicht überzeugt.

Es ist nützlich, wenn Sie verschiedene "Stile" für eine Seite haben. Beispiel:
generisch/ (xx sass-Dateien hier)
style1/ (xx Sass-Dateien hier, die Stile zu den generischen hinzufügen/überschreiben)
style2/ (xx Sass-Dateien hier, die Stile zu den generischen hinzufügen/überschreiben)
style1.sass (einfach: @import generisch/_, style1/_)
style2.sass (einfach: @import generisch/_, style2/_)

Warum konnten Sie nicht einfach _generic.sass haben, das alles im generischen Verzeichnis importiert?

Ich glaube nicht, dass es darum geht, was getan werden kann oder nicht, so viel wie es sein sollte. Letztendlich ist die Anordnung von Stylesheets wichtig und deshalb möchte ich, dass der Benutzer darüber nachdenkt. Es stimmt , dass Bibliotheken , die nur Mixins und Variablen sind , um unabhängig wie sind scoped Sheets definieren - aber ich mache mir Sorgen über eine allgemeine Fähigkeit bereitstellt , die falsch verwendet wird.

"Scoped Stylesheets" definieren?

Stylesheets, die die meisten oder alle ihrer Selektoren verschachteln. zB body.foo

Diese sind nicht garantiert auftragsunabhängig. Ein anderes Stylesheet an anderer Stelle könnte body.foo ... oder etwas anderes mit höherer Spezifität definieren.

Dann haben Sie wirklich kein funktionierendes Framework, weil Ihre Dateien nicht richtig getrennt sind.

Es gibt viele Möglichkeiten für Leute, ihr CSS zu vermasseln. Wir können ihnen diese Lösung anbieten und erklären, wann sie gegenüber dem Import einzelner Dateien verwendet werden sollte.

Indem Sie diese Funktion nicht implementieren, geben Sie Entwicklern, die dies möchten, um bereichsbezogene Stylesheets zu implementieren, die folgenden zwei Möglichkeiten:
1) Importieren Sie jede Datei einzeln manuell (was eigene Fehler verursachen kann, da Sie nicht benachrichtigt werden, wenn Sie eine Datei verpasst haben)
2) Implementieren Sie ein Build-System, um diese Dateien dynamisch hinzuzufügen (was eine Verschwendung ist, da mehrere Personen dasselbe implementieren)

Es ist sicherlich nicht der Fall, dass die gesamte Reihenfolgeabhängigkeit von Stylesheets mit Geltungsbereich das Ergebnis einer schlechten Trennung von Belangen ist. Erwägen:

body.foo .baz {
  color: blue; }

body.bar .baz {
  color: red; }

Dieses Stylesheet ist gut getrennt, aber immer noch reihenfolgeabhängig.

Auf jeden Fall ist die Vorstellung falsch, dass jeder, der diese Funktion nutzt, die Risiken versteht. Die einzige Möglichkeit, sicherzustellen, dass jeder versteht, in welcher Reihenfolge seine Stylesheets importiert werden, besteht darin, diese explizit anzugeben.

Im Großen und Ganzen sind Stylesheets mit Geltungsbereich reihenfolgeunabhängig, aber es kann vorkommen, dass die Reihenfolge auch dann wichtig ist, wenn Bedenken korrekt getrennt werden.

Das stille Ignorieren von Importen, die nicht gefunden werden, ist in sass3 kein Thema mehr. Nur CSS-Importe werden stillschweigend ignoriert.

Ich habe eine Sass-Datei, die ungefähr 60 andere importiert. Ich ändere es, wenn Dateien hinzugefügt oder entfernt werden, und denke dabei immer an die Reihenfolge. Es schien mir nie eine Last zu sein, sondern eher ein notwendiger Schritt.

Wenn meine Importe nicht gefunden werden (ich gebe immer .sass für Importe an), schlagen meine Tests fehl.

Es gibt ein Addage: so einfach wie möglich und nicht einfacher.

Mein Bauchgefühl sagt mir, dass dies die Dinge zu einfach macht und alle Zeiteinsparungen durch eine Debugging-Sitzung verloren gehen. Ich stimme dafür, dass wir dies vorerst beiseite legen. Wenn jemand ein Sass-Plugin erstellen möchte, das diese Funktion bietet, wäre ich sehr daran interessiert zu sehen, wie es für diese Benutzer funktioniert.

Ich denke, Richards Punkt war, dass es keinen Fehler gibt, wenn ein Teil erstellt wird, aber kein Import dafür hinzugefügt wird. Ich nehme an, dies könnte gemildert werden, indem man nach unbenutzten Teils sucht und Warnungen dafür ausdruckt.

Ich werde weitermachen und das schließen.

gah, das ist scheiße ... ich habe einen Ordner namens page_specific/ in den Assets meiner Rails-App ...
diese sollten alle in den großen Asset-Blob kompiliert werden, und sie sind jeweils vollständig eingehüllt
body#page1 {}, body#page2 {} usw...

Es besteht keine Chance, dass sie von der Bestellung abhängig sind, und ehrlich gesagt dieses ganze "Sie werden es verpassen! Nein!!!!!!" Mist ist beleidigend.

Wenn ein Benutzer dieser Funktion feststellt, dass die Reihenfolge wichtig ist, kann er die Dateien einfach in einer expliziten Reihenfolge importieren oder die Stile so umgestalten, dass sie nicht reihenfolgeabhängig sind... (

sicherlich fällt uns eine Möglichkeit ein, dieses kleine Bestellproblem zu minimieren. deterministische Ordnung ist ein Anfang. es @import-dir zu nennen, und eine Dokumentation des potenziellen Bestellproblems würde ebenfalls helfen. rails bietet bereits require_tree an, und die Dinge dort scheinen gut zu funktionieren. Die einzige Ausnahme besteht darin, dass Dateien einzeln kompiliert werden, wodurch meine Mixins und Variablen auf den Boden fallen. Ich stelle fest, dass die Mixins der eine Teil sind, der als explizit auftragsunabhängig platziert wurde, also warum kann das nicht für Sass funktionieren, wenn es für alle anderen funktioniert?

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

@chriseppstein super ! (und sorry, dass ich alle wie ein Wahnsinniger geschimpft habe)