Moderne CSS: So schreibst du besseren, fehlerfreien, skalierbaren Code

1. Einführung: Wie viele Menschen, bin ich völlig zufällig ins Netz gekommen. Ich dachte, ich würde viele Jahre ein schlechter Arschgrafik-Designer sein, und ich fühlte mich viel mehr in Entwicklung verliebt als nie mit Design. Hey, ich bin Harry, ich bin ein Berater Webentwickler und Performance-Ingenieur aus Großbritannien. In den letzten sechs Jahren habe ich bei vielen Veranstaltungen gesprochen. Ein großer Teil davon ist IT CSS oder Inverted Triangle CSS, und das werden wir heute lernen. IT CSS ist eine Methodik, eine Art, über CSS nachzudenken. Es wird Ihnen helfen, Projekte über einen sehr langen Zeitraum zu wachsen und zu skalieren. Das umgekehrte Dreieck ist ein sehr diagrammatischer Überblick über ein ganzes CSS-Projekt. Grund, dass wir ein Dreieck haben, ist, weil jede der drei Seiten einen der Kernmandanten von Inverted Triangle CSS darstellen . Unabhängig davon, ob Sie SaaS oder LaaS oder Vanilla CSS oder Host CSS oder sogar eine CSS in JS Lösung verwenden , IT CSS trainiert Sie genau dort, wo Sie jede andere Komponente von Zeile Null bis Zeile 15.000 Ihres Projekts platzieren sollten . Also die ersten paar Lektionen in diesem Kurs, vielleicht ziemlich theoretisch, viele Diagramme, viele Dinge zeichnen, und wirklich den Kopf zu bekommen , wie IT CSS funktioniert, theoretisch. Sobald wir das ganze Zeug behandelt haben, tauchen wir direkt in eine Codebasis ein und schauen Beispiele dafür, wie IT CSS als Codezeile auf dem Dateisystem zusammenkommt. Die gute Nachricht ist, dass Sie nicht bereits ein Experte in CSS sein müssen , um mit IT CSS beginnen zu können. Wenn Sie ein einfaches Verständnis der Grundlagen von CSS haben, können Sie sofort mit der Verwendung von IT CSS in Projekten beginnen. Ich bin unglaublich aufgeregt, Ihnen alles über IT CSS beizubringen. Also lasst uns anfangen. 2. Die Probleme mit CSS: Um ITCSS vollständig zu verstehen, ist es wichtig, dass wir uns die Probleme ansehen, die wir lösen wollen. CSS ist eine Sprache, die vor über 20 Jahren entwickelt wurde. Wir verwenden immer noch, um schlechte Anwendungen zu erstellen. Das ist kein Problem für sich selbst, aber einige der Probleme, die im Maßstab verhindern, sind Dinge, die wir angehen müssen. Die Tatsache, dass alles global funktioniert, bedeutet beispielsweise, dass jede Regel möglicherweise von einer anderen erben oder ihre Stile an etwas anderes weitergeben kann. Dies muss sehr sorgfältig gehandhabt werden. CSS ist auch unglaublich abhängig von der Quellreihenfolge. Großen und Ganzen, was zuletzt geschrieben wird, ist das, was angewendet wird. Das bedeutet, dass wir die Reihenfolge, in der wir unsere Codebasis strukturieren und aufbauen, sehr genau im Auge behalten müssen. Fügen Sie jedoch hinzu, dass die Tatsache, dass wir Spezifität haben. Wir können diese Logik sowieso komplett invertieren und Selektoren mit einer höheren Spezifität als andere können Dinge auf etwas unerwartete Weise überschreiben. Wir können all diese potenziellen Fallstricke. Wir müssen ein System zur Verwaltung von CSS entwerfen, das diese Funktionen in einer Weise formalisieren und strukturieren kann , die für uns und nicht gegen uns funktioniert. Es wäre jedoch völlig unsachgemäß und unfair, alles auf CSS zu beschuldigen. Die Tatsache, dass CSS seit über zwei Jahrzehnten den Test der Zeit bestanden hat, zeigt, dass es potenziell etwas gibt, das wir als Entwickler auch falsch machen. Entwickler haben viele verschiedene Codierungsstile. Ein Entwickler könnte Code schreiben, der genau wie jemand anderes funktioniert, aber sehr anders aussieht. Vielleicht, wir, um dies zu verwalten. Also haben wir eine einheitliche Art und Weise, in einem Team zu arbeiten. Entwickler sind auch berühmt schlecht darin, Dokumentation zu schreiben. Ich glaube nicht, dass ich jemals an einem Projekt gearbeitet habe, das genau die richtige Menge hatte. Was wäre, wenn wir unsere Code-Dokumentation erstellen könnten? Wenn wir mit der Arbeit an einer gemeinsamen Methodik beginnen können, können wir vielleicht ein Projekt erstellen, ohne Reams und Reams der Dokumentation zu benötigen. Großes Problem, dass Teams anstatt Einzelpersonen anwesend sind, ist, dass CSS wahrscheinlich die einzige Sprache ist , die jedes einzelne Mitglied eines Entwicklungsteams schreiben wird. Ich habe noch nie eine Zeile von Node.js geschrieben. Ich schreibe keine MySQL. Aber jede einzelne Person, mit der ich je gearbeitet habe, hat zumindest ein CSS geschrieben. Diese Vielfalt und Fähigkeiten, die alle zu einer Sprache beitragen, bedeutet, dass wir nicht garantieren können, dass jeder so viel weiß wie die nächste Person. Wenn wir eine Methodik entwerfen könnten, die den Stress und den Schmerz davon abnimmt, könnten wir Nicht-Experten dazu bringen, CSS in einer nicht-nachteiligen Weise beizutragen. Wenn wir all das berücksichtigen und mitfühlend Arbeit von Teams und die Art und Weise, wie CSS funktioniert, was wir brauchen, ist ein Rahmen und eine Arbeitsweise, die helfen, diese Probleme zu lösen. Dieser Rahmen ist ITCSS. Lasst uns eintauchen. 3. CSS ohne ITCSS: Was also anfangen wird, ist es sehr diagrammatisch zu visualisieren, wie ein vorhandenes Legacy- oder Nicht-ITCSS-Projekt aussehen könnte und wo die Probleme in Stylesheets auftreten , die keine formalisierte Methodik wie ITCSS verwenden. Stellen Sie sich also vor, wenn Sie so wollen, dass dieses Rechteck hier ein ganzes bestehendes CSS-Projekt darstellt. Dies ist eine CSS-Datei. Jetzt könnte dies eine tatsächliche CSS-Datei einer einzigen monolithischen Datei sein, oder es könnte das Ergebnis der Kompilierung vieler verschiedener SaaS-Dateien in eine große Datei sein. Wie wir zu diesem Punkt kommen, ist momentan nicht wirklich wichtig. Stellen Sie sich vor, dass dies Ihr gesamtes CSS-Projekt ist, und um die Dinge ein wenig leichter zu verstehen, sagen wir, wir haben Zeile Null, unten auf Zeile 3.000. Sagen wir, es ist ein nettes kleines Projekt. Nun, traditionell, die Art, wie wir normalerweise CSS schreiben, ist, dass wir uns das Design ansehen, das wir bauen und wir würden die ersten Features identifizieren. Wir könnten uns das Design ansehen und gut sehen, wir müssen einen CSS-Reset verwenden. Also habe ich meinen CSS-Reset irgendwo nahe am Anfang gesetzt, weil das Sinn ergibt. Also beginnen wir damit, etwas Gerüst zu setzen, vielleicht eine Art Framework, das CSS zum Anfang füllt, und schauen dann weiter in das Design und entscheiden, dass gut, das erste, was in einer Photoshop-Datei oder der skizzierten Datei ein Header ist. Also, ich lege mein Header-CSS hier. Jetzt bauen wir hier Stylesheets um eine visuelle Sprache. Die Struktur eines Entwurfs. Dies ist eine sehr häufige Art, CSS zu schreiben, und in den meisten Fällen, besonders bei kleinen Projekten, wird dies normalerweise funktionieren. Wenn ein Projekt zu wachsen beginnt, werden wir beginnen, Probleme zu treffen. Was wir hier tun, ist, dass wir CSS in einer sehr, sehr menschlichen Ordnung schreiben. Dies ist die Art und Weise, wie ein Mensch CSS betrachtet. Das Problem, das wir haben, ist jedoch, dass es einem Browser egal ist, ob der Header das erste ist, was in einer Photoshop-Datei ist oder nicht. Alles, was einem Browser wichtig ist, ist, welche Spezifität ein Selektor haben könnte, wie weit dieser Selektor erreicht sein könnte, was von diesem Selektor erben könnte. Wenn wir also anfangen, unser CSS auf eine sehr menschliche strukturierte Weise zu schreiben, werden wir bald auf Probleme stoßen, bei denen vielleicht das erste bisschen CSS gut funktioniert, und wir schreiben ein weiteres bisschen CSS und das funktioniert gut. Wir schreiben wieder ein drittes bisschen CSS stoßen auf keine Probleme. Plötzlich könnten wir ein viertes bisschen CSS schreiben, aber aus irgendeinem Grund wird hier von diesem CSS überschrieben. Dies könnte durch die Spezifität Wände verursacht werden, dies könnte durch Selektoren verursacht werden, die sich gegenseitig eine Prominenz bekämpfen, es könnte durch eine beliebige Anzahl von Dingen verursacht werden, aber ohne unsere CSS-Architektur durch Schreiben vollständig zu berücksichtigen CSS in dem, was ich als sehr menschliche Art betrachten würde. Nun, nicht wirklich sehr sympathisch, um CSS tatsächlich zu helfen funktioniert oder wie der Browser es schätzen würde, dieses CSS zu erhalten. Also, jetzt haben wir ein Problem. Wir haben hier ein Problem, bei dem wir etwas beheben wollten. Wir könnten dieses bisschen CSS aufräumen und das Problem beseitigen, aber das ist normalerweise nicht das, was ein Entwickler tun würde. Wir könnten Zeitbeschränkungen haben, wir haben Fristen, aber was wir höchstwahrscheinlich tun, ist, etwas zu hacken, um es zu beheben. Also könnten wir am Ende einen wichtigen hier unten kleben etwas ziemlich böses machen. Sobald wir das Problem gelöst haben, machen wir weiter. Das nächste bisschen CSS funktioniert zufällig gut. Das nächste bisschen CSS funktioniert gut. Das nächste bisschen CSS wird dadurch überrannt, und dann überschreibt dieses Bit hier dieses Bit. Also, wir haben ein Problem weiter oben auf dem Stapel. Bei einem großen Projekt kann ich fast garantieren, dass jeder Entwickler in eine Situation wie diese geraten ist und diese Frustration die Produktivität massiv reduziert. Viel Zeit wird damit verbracht, sich in eine Ecke zu malen und dann zu versuchen, es wieder zu bekämpfen, und in der Regel wird das Problem immer schlimmer. Wenn Sie nicht viel Zeit dem Refactoring des CSS widmen, werden Sie diesen Weg fortsetzen, und über einen Zeitraum von Wochen, Monaten, vielleicht sogar Jahren wird das Problem so schlimm werden, dass Sie komplett neu starten. Lasst uns weitermachen. Schreiben Sie noch etwas CSS. Das ist in Ordnung, das ist in Ordnung, das überschreibt, das ist eine feine, feine, die überschrieben wird, hier außer Kraft gesetzt wird. Diese konsequente oder ständig unberechenbare Natur, diese Art von Ineffizienz ist sehr verbreitet bei großen Projekten, und so beginnen CSS-Projekte außer Kontrolle zu geraten. Also, nachdem eine lange genug Zeit in diesem Projekt ausgereift ist, stellen wir fest, dass wir all diese Ineffizienzen ziemlich häufig haben. Normalerweise werden Sie diese Frustrationen aus erster Hand identifiziert, während Sie an einem Projekt arbeiten, werden Sie feststellen, dass wir diese Probleme bekommen. Sie werden feststellen, dass vielleicht ein sechs Monate altes Feature, überschreibt eine Funktion, die Sie tatsächlich jetzt schreiben. Ein weiterer guter Weg, eine einfache Möglichkeit, diese im Browser zu identifizieren, ist im Chromes-Inspektor. Wenn Sie mit der rechten Maustaste klicken und das Element inspizieren, wenn Sie dort eine Menge CSS mit Zeilen sehen, viele Durchgestrichen, stellt dies eine enorme Ineffizienz dar. Dies stellt CSS dar, das irgendwann geschrieben, auf der Festplatte gespeichert, in ein Styler-Sheet kompiliert, an einen Webserver gesendet, schließlich an einen Benutzer gesendet, an seinen Browser gesendet wurde und es nie verwendet wurde. Es ist in der Effizienz, wo wir ständig CSS überschreiben , das viele Monate zuvor geschrieben wurde. Nun, wenn dieses Diagramm hier die erste Phase eines CSS-Projekts darstellt, ist es vielleicht der erste Build eines Projekts, die erste Reihe von Features für ein Projekt. Probleme werden noch schlimmer, wenn wir beginnen, neue, unterschiedliche Funktionen oder neue Phasen hinzuzufügen . Also, wenn dies Phase 1 darstellt, typischerweise ist der Ort, an dem wir Phase 2 eines CSS-Projekts setzen würden, leider, neigen wir dazu, am Ende zu schrauben. Dies ist, wie CSS in der Regel zu funktionieren neigt. Wir schnallen die Dinge einfach am Ende. Phase drei, bleib am Ende davon noch. Das Problem wird also verschärft, wo nicht nur der Code in jeder Phase gegen sich selbst kämpft, auch ganze Phasen des Projekts bekämpfen sich gegenseitig. Nun, wenn Sie schauen, sind wir mit diesem seltsamen Phänomen gelandet wo unser CSS irgendwie auf Phase eins oben gelegt ist, Phase 2, Phase 3, und das erinnert mich daran, die fossile Platte zu betrachten. Richtig? Sie haben hier ein kreidees CSS, ein Jurassic CSS hier. Es gibt absolut keinen Grund, warum ich in der Lage sein sollte, dein CSS zu schneiden und es chronologisch zu lesen. Es gibt keinen Grund, warum Ihr CSS-Projekt Ihre Produkt-Roadmap spiegeln sollte. Aber die meiste Zeit, wenn wir keine strukturierte Arbeitsweise haben, ist genau das, was passiert. Ich sollte nicht in der Lage sein, herauszufinden, dass Sie an diesem Datum diese Funktion nur aus dem Blick auf ein Styler-Blatt veröffentlicht haben. Durch die Verwendung von IT CSS können wir all diese Probleme annehmen und eine Struktur neu vorstellen, in der dies verschwindet. Diese Probleme, die wir hier erleben, das könnte durch diesen sehr unberechenbaren Jumpier um die Natur, den wir in das CSS-Projekt bekommen, gestreift haben , kann durch eine Reihe von Dingen verursacht werden. Fehlgemanagte Spezifität. Also, Verwendung von Selektoren, die zu schwer sind, könnte es durch das Zeichnen von Dingen in einer ineffizienten Reihenfolge oder einer unpraktischen Reihenfolge verursacht werden, oder es könnte durch das Entwerfen von Dingen oder Schreiben von Code verursacht werden, zu viel und meinungsvolle Stände benötigt zu früh. Inverted Dreieck CSS zielt darauf ab, alle diese drei Kernmieter zu nehmen und formalisieren sie bilden jede Seite des Dreiecks. 4. Specificity Wars: Werfen wir einen Blick darauf, was das Dreieck tatsächlich umfasst. Wir haben kurz Spezifität erwähnt. Spezifität ist die inhärente Gewichtung eines Selektors, seine prominente, seine Fähigkeit, andere unähnliche Selektoren zu überschreiben. Spezifität ist eines der schwierigsten Dinge, die in einem CSS-Projekt im Maßstab zu verwalten sind. Eine der ersten Schlüsselregeln beim Schreiben von CSS für große Projekte ist, immer die Verwendung des ID-Selektors vermeiden. Wenn Sie mehr darüber erfahren möchten, warum wir den ID-Selektor in CSS gesperrt haben, lesen Sie die Ressourcen. So ist Spezifität ein großes, großes Problem beim Schreiben von CSS im Maßstab. Um Entwicklungsteams dabei zu helfen, die Spezifität ihres gesamten Projekts zu visualisieren, habe ich ein Konzept eines Spezifitätsdiagramms entwickelt. Was das Spezifitätsdiagramm tun wird, ist, das vorherige Diagramm zu nehmen, [unhörbar] das gesamte Stylesheet, und zeichnen Sie die Spezifität seiner Selektoren. Es ist ein einfaches Liniendiagramm. Wir zeichnen die Spezifität eines Selektors. Auf der X-Achse zeichnen wir die Liniennummer, an der dieser Selektor angezeigt wird. Nun, beginnend mit einem bestehenden Projekt, beginnen wir vielleicht mit dem Stern-Selektor. Der Stern-Selektor trägt einen Spezifitätswert von Null. Also, in Zeile 1 bis Zeile 3.000, könnten wir mit einem Selektor mit Spezifitätswert von Null beginnen. In einem bestehenden oder Legacy-Projekt sind die Chancen sehr hoch, dass wir unsere Spezifität nicht richtig verwaltet haben. Dies könnte zu einem Spezifitätsdiagramm führen, das ungefähr so aussieht. Vielleicht beginnen wir mit einem Stern-Selektor, vielleicht einigen Element-Selektoren, jemand benutzte eine ID, vielleicht einige Klassen darunter und verschachtelte Klasse. Was wir sehen werden, wenn wir durchgehen, ist, wir die verschiedenen Arten von Selektoren und ihre relativen Besonderheiten in einem Diagramm darstellen, das ungefähr so aussehen könnte. Es ist wichtig, an dieser Stelle zu beachten, dass es sich um ein rein theoretisches Modell handelt. Dies ist kein tatsächliches Spezifitätsdiagramm eines tatsächlichen Projekts. Wenn Sie ein echtes Spezifitätsdiagramm sehen möchten, lesen Sie bitte die Ressourcen. Es stehen Werkzeuge zur Verfügung, die eine Eingabe-Stylesheet verwenden und Ihnen ein genaues Diagramm erstellen. Für den Moment, aber sehen Sie dies nur als ein mentales Modell, um zu helfen das Problem der falsch verwalteten Spezifität visualisieren. Ein vorhandenes oder veraltetes Projekt, ohne dass seine Spezifität ordnungsgemäß verwaltet wird, kann ein Diagramm aufweisen, das so aussieht. Wie Sie sehen können, gibt es sehr wenig Konsistenz. Nun, das Problem ist nicht notwendigerweise hier, mit hohen Besonderheiten. Das Problem besteht, wenn wir Code in einem Bereich mit geringer Spezifität beitragen möchten. Wenn wir einige Änderungen oder Ergänzungen vornehmen oder eine neue Funktion zu diesem bestimmten Teil der Codebasis hinzufügen möchten , haben wir die Sorge, dass dieser Selektor uns vielleicht versehentlich überschreiben könnte. Wenn das der Fall ist, müssen wir hier möglicherweise etwas wie einen wichtigen oder verschachtelten Selektor oder eine andere Art von Hack einführen , um die Spezifität dieses Selektors künstlich zu erhöhen, um diesen zu überschreiben. Dies wiederum bringt uns ein anderes Problem, denn was ist, wenn dieser Teil der Codebasis jetzt diesen überschreiben muss? Wir stecken in dieser Einbahnstraße fest, wo wir nicht einfach an jedem Punkt aushelfen können, wir können nicht einfach aus diesem Modell ablehnen. Wir befinden uns in den sogenannten Spezifitätskriegen, wo wir immer genau den gleichen Weg bekämpfen müssen, was den Rest des Projekts immer schlimmer macht. Dies ist, was wir typischerweise ein schlechtes Spezifitätsdiagramm nennen. Also, bei einem realen Projekt, ist die Art von Graphenform, die wir suchen, ständig nach oben. heißt, wir wollen, dass die Spezifität über das gesamte Projekt schrittweise zunehmen wird , wenn wir von Linie 1 bis zum Ende des Projekts gehen, in unserem Fall ein relativ kleines Projekt von nur 3.000 Linien. Wenn wir das visualisieren wollen, würde es ein bisschen so aussehen. Ein Spezifitätsdiagramm, das ständig nach oben tendiert, hat den unmittelbaren Vorteil , dass alles, was später im Projekt definiert wurde, automatisch alles, was zuvor definiert wurde, außer Kraft setzt, nur aufgrund seines Standorts. Das praktische Ergebnis davon ist, dass ein definiertes Merkmal, zum Beispiel, direkt hier, automatisch alles überschreiben sollte, was zuvor definiert wurde, aufgrund dessen, wo es lebt. Dasselbe kann von einer Funktion gesagt werden, die zum Beispiel hier hinzugefügt wurde. Dies beginnt sofort, das Problem älterer oder vorhandener oder sogar veralteter Features zu beseitigen , die neue Arbeit überschreiben. Jetzt, da wir die Form des theoretischen, gesunden, guten Spezifitätsdiagramms erreicht haben, können wir damit beginnen dies in etwas greifbareres und praktikableres nachzurüsten. Wir können beginnen, Slices aus dieser theoretischen Codebasis zu nehmen und damit beginnen, Verzeichnisse auf dem Dateisystem zu erstellen, die unsere verschiedenen Arten von CSS beherbergen. Die erste Scheibe oder Ebene in unserem umgekehrten Dreieck ist ziemlich generischen Reset-Typ von Stilen gewidmet , Dinge wie normalize.css oder Ihr CSS-Reset, jede Art von globaler Box-Größe, alles, was sehr weit verbreitet ist für das Projekt hat aber eine sehr, sehr geringe Spezifität. Dieses Verzeichnis wird diese Art von Code beherbergen und hat den Namen generisch. In der Regel würden wir feststellen, dass der generische Layer in fast jedem Projekt identisch wäre , an dem Sie arbeiten. Sie haben wahrscheinlich genau die gleiche normalize.css für verschiedene Projekte verwendet. Sie haben wahrscheinlich genau die gleiche reset.css für verschiedene Projekte verwendet. Dies bedeutet, dass diese Ebene sehr kopier- und einfügbar ist und in vielen verschiedenen Projekten oder Produkten bereitgestellt werden kann . Nach der generischen Schicht beginnen wir, unsere Spezifität zu erhöhen. Wir treten in die sogenannte Elementschicht ein. Die Elemente-Ebene enthält vorhersehbar alle CSS, die dem Styling von HTML-Elementen gewidmet sind. Zum Beispiel, wie sieht ein Element ohne eine Klasse aus? Wie würde ein h1-Element ohne eine Klasse aussehen? Wir haben die Spezifität etwas erhöht, und wir haben begonnen, die Funktion des CSS zu ändern, um mit dem Hinzufügen einiger Designstile zu beginnen. Aber es ist immer noch eine sehr geringe Spezifität und ziemlich breite Schicht. Eine gute Faustregel beim Nachdenken über die Elementschicht besteht darin, sich vorzustellen, wie Ihre Website aussehen würde , wenn sie keine Klassen oder IDs irgendwo in HTML hätte. Wie würde das CSS ein einfaches h1 und Absatz aussehen lassen? Wie lässt CSS einen einfachen Link zu einer ungeordneten Liste aussehen? Jenseits der Elemente-Ebene treten wir in das, was als Objekt-Layer bekannt ist. Der Objekte-Layer ist die erste Ebene, in der wir Spezifität auf Klassenebene einführen dürfen . Während die generische Ebene mit etwas so geringer Spezifität wie der Stern-Selektor beginnt , befasst sich die Elementschicht nur mit HTML-Elementselektoren. Der Objekte-Layer darf damit beginnen, sich mit Spezifität auf Klassenebene zu beschäftigen. In CSS ist ein Objekt ein strukturelles Entwurfsmuster. Es stammt von einer Denkschule namens Objektorientierte CSS, die von Nicole Sullivan entwickelt wurde. Objektorientierte CSS könnte ein Skillshare Kurs an sich sein, also beziehen Sie sich bitte auf die Ressourcen für zusätzliches Lernen. Aber im Moment müssen Sie nur wissen, dass der Objekte-Layer die erste Ebene ist , die Spezifität auf Klassenebene einführt und sich mit strukturellen Entwurfsmustern befasst. Das sind Dinge wie Gittersysteme. Die nächste Ebene, die wir im umgekehrten Dreieck begegnen, wird als Komponentenlayer bezeichnet. Für mich ist die Komponentenschicht bei weitem die wichtigste. Die Komponentenschicht ist die Sache, die die Mehrheit von dem, was wir als die Website kennen, enthält . Komponenten sind Dinge wie Schaltflächen oder Navigationselemente oder Karussells. Der Komponenten-Layer enthält das, was der Benutzer sehen und mit ihm interagieren würde. Sie sollten sich die vorhergehenden Schichten als sehr architektonisch vorstellen. Dies sind die Dinge, die dem Benutzer sehr unwahrscheinlich bewusst sein wird. Dem Benutzer ist es egal, ob Sie normalize.css verwenden, dem Benutzer egal, welches Grid-System Sie verwenden. Die vorherigen drei Schichten sind, wo wir die meisten der architektonischen Probleme behandeln, und die Komponentenschicht ist, wo wir beginnen, Kapselung zu erreichen. Der Komponentenlayer würde aus einzelnen Dateien bestehen, die möglicherweise ein Karussell, ein Dropdown-Menü oder eine Schaltfläche steuern würden . Proportional macht die Komponentenschicht den größten Teil des Projekts aus, da die meisten Ihrer Website Komponenten wären. Dies liegt daran, dass Sie die meisten Änderungen und Ergänzungen an Ihrem Projekt in diesem Teil der Codebasis vornehmen würden. Sehr wichtig, deshalb kapseln wir den Code hier sehr gut ein. Das endgültige der standardmäßigen ITCSS-Layer wird als Dienstprogramm-Layer bezeichnet. Nun, was Sie hier bemerken werden, ist diese enorme Spitze gegen Ende. Das liegt daran, dass die Dienstprogrammschicht für all das böse CSS reserviert ist , über das Sie nicht wirklich sprechen möchten. Der Dienstprogramm-Layer ist, wo Sie Dinge wie Hacks oder Ihre IE7-Stylesheets löschen können. Hier können Sie auch mit wichtigen davonkommen. Nun, wenn wir zurücktreten und uns dieses fertige Diagramm ansehen, können wir beginnen, eine greifbarere und aussagekräftigere Ausgabe zu sehen. Wir können sehen, dass, wenn wir von Linie 1 zu Zeile 3.000 unseres Projekts voranschreiten, die Spezifität unseres CSS immer zunimmt. wir diese Erhöhung der Spezifität durchlaufen, beginnen wir, vertikale Scheiben aus dem Projekt zu nehmen und unser CSS um bestimmte Funktionen zu kategorisieren. 5. Die drei Seiten von ITCSS: Nun, Sie fragen sich wahrscheinlich, wie wir es geschafft haben, so weit zu kommen und noch nicht einmal ein Dreieck zu sehen. Nun, wir werden uns genau ansehen, wo das hineinpasst. Wir haben gerade über Spezifitätsdiagramme und eine ganze Menge Details gelernt, das Wechselrichterdreieck arbeitet an drei Kernprinzipien und das wichtigste davon ist Spezifität. Nun stellt dieses Diagramm wieder die Gesamtheit Ihres CSS-Projekts dar, ob es sich um eine einzelne CSS-Datei handelt oder ob dies das Ergebnis vieler SAS-Dateien war , die in einem resultierenden Stylesheet kompiliert wurden, dieses Dreieck repräsentiert all diese zusammen. Also, wieder, wir starten Linie Null und wir gehen runter auf eine Linie 3.000. Jede Kante des Dreiecks stellt eines der drei Kernprinzipien dar. Die erste ist die Spezifität. Die Spezifität wird immer zunehmen, wenn wir das Projekt von Linie Null in Richtung 3.000 durchlaufen haben. Unsere Spezifität sollte nur immer zunehmen. Das zweite Kernprinzip, das ITCSS untermauert, ist ein Prinzip, das Explizitness genannt wird. Explizitness betrachtet die Idee, wie eigensinnig ein Stück Design sein könnte. Wenn beispielsweise nur eine Schaltfläche auf der gesamten Website einen roten Hintergrund haben muss, würden Sie diesen roten Hintergrund nicht auf jedes einzelne A-Element anwenden, würden Sie bis zu einem späteren Zeitpunkt im Projekt warten, um diese eine Schaltfläche zu identifizieren und dort anzuwenden. Viele der Gründe, warum CSS-Projekt beginnt schief zu gehen und beginnen auseinander zu fallen, es liegt daran, dass die Leute eine Tendenz haben, zu viel zu früh zu entwerfen und dann den Rest ihres Projekts damit zu verbringen, das rückgängig zu machen. Explizitness erzwingt etwas Zurückhaltung und lässt Entwickler nur für zusätzliche Designänderungen entscheiden, wenn sie erforderlich sind. Das dritte und letzte Kernleitprinzip hinter ITCSS bildet die letzte Seite des Dreiecks und bringt in der Tat alles zusammen, dieses Prinzip wird als Reichweite bezeichnet. Nun, während Spezifität und Explizität sowohl zunehmen, als auch wenn wir das Projekt durchlaufen, wird die Reichweite tatsächlich abnehmen. Reach befasst sich damit, wie viel von der Seite oder der Komponente oder tatsächlich der gesamten Website ein bestimmter Selektor beeinflussen kann. Ein sehr weit reichender Selektor, es ist, als ob der Stern-Selektor das gesamte DOM beeinflussen kann. Es hat auch eine sehr geringe Spezifität. Umgekehrt kann eine einzelne Klasse nur einen einzelnen DOM-Knoten gleichzeitig beeinflussen, den DOM-Knoten, dem zugeordnet ist, und Klassen haben auch eine viel höhere Spezifität. Die Reichweite nimmt ab, wenn wir das Dreieck hinunter gehen und ist das, was ein Dreieck überhaupt ausmacht. Ohne Reichweite wäre es das umgekehrte Quadrat, von dem ich denke, dass es nur ein Quadrat ist und Quadrate keine Werkstätten verkaufen. Reach bringt das gesamte Dreieck zusammen und verringert die Menge der Seite oder Komponente eines DOM, das wir jederzeit berühren können. Also, wie es meine Absicht ist, ist das alles sehr hoch. Was ich tun werde, ist schnell ein Beispiel Selektoren neben dem Dreieck zu kritzeln , um Ihnen zu zeigen, welche Art von Code Sie erwarten könnten, wo zu finden. Ich habe bereits erwähnt, ist der Stern-Selektor , der einen Spezifitätswert von genau Null trägt. Der Stern-Selektor kann jeden einzelnen DOM-Knoten auf einer Seite beeinflussen, Kuh ist sehr geringe Spezifität und sollte daher auch sehr explizit sein. Sie möchten nicht die Schriftgewichtskugel auf den Stern-Selektor anwenden. weiter voranschreiten, können wir vielleicht einen A-Element-Selektor finden. Das A-Element hat eine höhere Spezifität als ein Stern-Selektor und kann daher nur etwas weniger des DOM beeinflussen, nur jedes Ankerelement kann gestylt werden. Weiter voranschreitend, haben wir einen expliziteren Design-Stil, vielleicht werden wir nicht einen Knopf stylen. Also, ein Knopf ist eine zunehmende Explizität. Eine Erhöhung der Explizitität trägt eine natürliche Zunahme der Spezifität, da wir einen Selektor wie.button verwenden müssten. Was Sie neigen dazu, zu finden, ist, dass Spezifität und Explizität relativ gleichermaßen übereinstimmen. Alles, was eine Spezifität davon hat, würde eine entsprechende Explizität haben. Sie möchten den Designstil einer Schaltfläche nicht gegen die Spezifität des Stern-Selektors anwenden , was sehr schädlich wäre. Stellen wir uns für eine Sekunde vor, dass wir eine bestimmte Art von Schaltfläche haben, vielleicht eine Schaltfläche, die von einem Benutzer nicht angeklickt werden kann, weil sie keine korrekte E-Mail-Adresse eingegeben haben. Dafür müssten wir noch einen Selektor bekommen. Jetzt ist unser Design-Stil expliziter geworden, weil es nicht nur eine Schaltfläche ist, sondern eine Art Schaltfläche, die nicht verwendet werden kann. Diese Zunahme der Explizität muss möglicherweise zu einer Erhöhung der Spezifität führen. Also, wir könnten einen Selektor wie. deaktiviert, was ein Element angibt, das nicht verwendet werden kann. Unter unserer Spezifität und Explizität erreichen wir natürlich die Reichweite dieses Selektors. Die Disable-Klasse würde nur angewendet werden, um die eine Schaltfläche zu einem bestimmten Zeitpunkt deaktiviert ist, daher ist es Reichweite sehr klein. Wenn wir das A-Element betrachten, das nach oben von 100 Links auf einer Seite liegen könnte, bedeutet dies, dass es einen Selektor verwendet, relativ geringe Spezifität hat, bedeutet auch, dass, weil es 100 Links auf einer Seite geben könnte, Wir können ihnen keinen übermäßig eigenwilligen Designstil geben und da es über 100 Links auf einer Seite geben könnte, ist die Reichweite dieses Buttons tatsächlich sehr hoch. So spielen sich die drei Schlüsselmetriken, die drei Kernprinzipien alle ineinander. Normalerweise werden Sie feststellen, wenn Sie zwei der drei Prinzipien gehorchen, erhalten Sie den dritten kostenlos ausgearbeitet. Wann immer Sie einem Projekt Code hinzufügen müssen, fragen Sie sich: „Wie explizit oder eigensinnig ist der Designstil?“ Wenn es sich um einen ziemlich eigenwilligen Designstil handelt, benötigen Sie einen äquivalent eigenwilligen Selektor , der daher eine Spezifität bringt. Durch einen ziemlich expliziten Design-Stil und eine hohe Spezifität, werden Sie leicht gehen, um die Reichen für Sie zu erarbeiten. Um kurz die Reichweite zu erweitern und was das für die Form unseres Projekts bedeutet, lassen Sie uns das Dreieck schnell als tatsächliche Kegelform und nicht als flaches Dreieck neu vorstellen. Diese Trichterform stellt nun dar, wie sich die Selektoren, während Sie von Linie Null zu Zeile 3.000 Ihres Projekts fortgeführt haben, immer weniger auf das DOM auswirken. Also, was Sie jetzt finden, ist jede Ebene verantwortlich für das Styling immer weniger von der Seite, während Sie Fortschritte. Die erste Schicht zielt auf fast alles, und schrittweise weniger, und weniger, und weniger, bevor Sie den Boden des Dreiecks erreichen oder jetzt, Ich denke, der umgekehrte Kegel, und Ihre Auswirkungen mit punktgenauer Präzision einzelnen DOM-Knoten gleichzeitig. Eine sinnvolle Analogie für diesen gesamten Workflow ist, wenn Sie sich vorstellen würden, dass ein Bildhauer eine Statue macht. Ein Bildhauer kann sich einem Steinbruch nähern und nach einem großen Marmorblock fragen. Nun, was der Steinbruch tun würde, ist vielleicht dieses Stück Marmor aus der Seite der Felswand zu sprengen und es in die Steinmühle zu nehmen, und die Steinmühle nimmt diesen großen Stein und macht es zu einem schönen praktikable Würfel. Dann, die Möglichkeit, das Stück Stein ins Studio zu nehmen, und würde einen großen Hammer und einen großen Meißel zu bekommen, und machte grob die Form einer Person. Nachdem sie das getan haben, bekommen sie einen kleineren Hammer und einen kleineren Meißel und fangen an, Details wie Finger zu setzen. Was wäre eine sehr ungewöhnliche Art zu arbeiten, ist, wenn dieser Sculpt nahm nur einen großen Block von Marmor grob kann ich nur sprengen aus meinem Rockface und Mode nur der perfekte Finger, der aus der Spitze davon ragt. Was ich hier versuche, ist genau das gleiche mit CSS zu tun, breite Striche früh in einem Projekt zu schneiden, um vielleicht 50 Prozent des schweren Heben abzudecken. Dann deckt das nächste Bit die nächsten 10 Prozent und dann fünf Prozent ab, bis wir diese kleineren und kleineren Arbeitsabschnitte auf immer weniger DOM-Knoten gleichzeitig abzielen. Arbeit auf diese Weise ermöglicht es uns, zielgerichtet zu bleiben und die Dinge gut zu verwalten, während wir immer weiter in das Projekt einsteigen. Also haben wir gerade eine Menge Diagramme gesucht, wir schauen nicht auf eine einzige Codezeile. Lasst uns jetzt zum Computer übergehen. Sehen Sie, wie dieses Zeug in einem Projekt zusammenkommt, auf dem tatsächlichen Dateisystem mit echtem CSS. 6. ITCSS in der Praxis: Also haben wir nur eine Menge Zeit dort verbracht, um sehr konzeptionelle Diagramme zu betrachten. Wir haben uns nicht eine einzige Codezeile angesehen. Also, was ich jetzt tun möchte, ist in ein Beispielprojekt einzutauchen, das ich gebaut habe. Das Beispielprojekt heißt Discover. Es ist eine mock Art von Reise-Website und es hat ein großartiges Repository, auf das Sie vollständigen Zugriff haben, also stellen Sie sicher, dass Sie die Ressourcen dafür überprüfen. Es wird auch auf der LINE-URL gehostet, so dass Sie genau sehen können, was wir erstellen. Aber werfen wir einen Blick, dies ist eine kleine Art von erstellten Projekt, das mit ITCSS erstellt wird. Das erste, was ich Ihnen zeigen möchte, ist, wie das auf dem Dateisystem aussieht, wie das tatsächlich im Finder aussieht. Nun, es ist ein sehr kleines Projekt, weil es nur zum Beispiel Sake erfunden wurde, also wirst du nichts Komplexes wie jede Art von Aufgabe sehen oder man hat irgendwelche Build-Pipelines, so etwas. Hier können wir beginnen, das Zeug des umgekehrten Dreiecks zu sehen. Das erste, was Sie bemerken werden, ist, dass wir eine main.scss-Datei haben, das ist unser einziger Einstiegspunkt. Diese eine Datei ist also dafür verantwortlich, alle anderen Aspekte des CSS-Projekts in ihre jeweilige Reihenfolge gemäß dem umgekehrten Dreieck zu importieren . Als nächstes werden Sie sehen, dass jede einzelne Schicht des Dreiecks ein entsprechendes Verzeichnis hat. Nun, das ist völlig optional. Eines der wichtigsten Dinge von ITCSS ist, dass es viele dieser Entscheidungen dem Entwickler überlässt. Früher hatte ich ein Setup, in dem ich kein Verzeichnis für jeden Typ von CSS-Datei hatte. Ich hatte gerade eine flache Verzeichnisstruktur, aber ich erkannte, dass das nach einer Weile wirklich schwer zu verwalten wird, also gehe ich zu einer Struktur mehr wie dieser, in der wir sehen können, dass jede Art von CSS-Selektor, jede Art von -Layer in einem Dreieck hat ein eigenes entsprechendes Verzeichnis. Ich habe alle Dateien für jede Ebene in diesem Verzeichnis gruppiert , das nach mir benannt ist, aber was ich auch tue, ist, dass ich jede meiner Dateien layer.file.scss benannt habe. Also, hier werden Sie elements.headings.css sehen. Hier könnten wir objects.layout.scss sehen. Wenn Sie den Layer-Namen innerhalb des Dateinamens haben, ist es sehr einfach zu verstehen, an welchem Teil das Projekt ich zu einem bestimmten Zeitpunkt arbeite. Aber auch hier ist dies völlig auf die Vorliebe der Entwickler zurückzuführen. Neben der Gruppierung jeder Art von Datei in seinem entsprechenden Verzeichnis möchte ich jede Datei auch nach der Ebene benennen, auf die sie sich bezieht. Also, was Sie hier sehen können, ist components.avatar.scss oder in dieser Datei oder seinem Ordner genau hier, wir haben objects.layout.scss. Der Grund, warum ich das mag, ist es schön, nur aus dem Dateinamen allein zu sehen, an welchem Teil des Projekts ich arbeite. Wenn ich objects.layout.scss in meinem Texteditor geöffnet habe, weiß ich genau, zu welchem Teil des Projekts ich beitrage. Werfen wir einen Blick auf unsere main.scss. Dies ist der Haupteinstiegspunkt. Dies ist die einzelne Quelldatei, die den gesamten Rest des Projekts komprimiert, und es ist diese Quelldatei, die später main.scss erzeugt. Wenn Sie main.scss in meinem Texteditor nachschlagen, werden Sie zuerst dieses Inhaltsverzeichnis bemerken. Auch hier ist dies völlig optional, dies ist Entwicklerpräferenz. Aber ich mag es, ein ziemlich manuelles Inhaltsverzeichnis an der Spitze meines Haupteinstiegs zu pflegen . Was ich damit tun kann, ist menschlich genau das aufzuschreiben , was im Projekt enthalten ist. Was Sie oft finden, ist, wenn Projekte größer werden und älter werden, viele Leute werden nicht vertraut mit welcher Art von CSS in diesem CSS-Verzeichnis existiert. Sie wissen nicht, welche Funktionen bereits existieren, was bereits gebaut wurde und so weiter. Unter Beibehaltung dieses eher manuellen, aber sehr menschlich lesbaren Inhaltsverzeichnisses, werden Entwickler immer darauf aufmerksam gemacht, was ihnen zur Verfügung steht. Wenn wir von einem Inhaltsverzeichnis ausgehen, werden wir beginnen, meine @import -Direktiven zu sehen. Also, was Sie hier sehen werden, ist mein Import für die Einstellungen und Tools Layer. Dies sind rein Vorprozess von Schichten. Dies enthält globale Einstellungen für mein Projekt z. B. typografische Maßstäbe oder Farbpaletten. Der Werkzeug-Layer enthält Dinge, die mit Mischungen oder Funktionen zu tun haben, die das Projekt möglicherweise benötigt. Lassen Sie mich zu den Schichten übergehen, die wir zuvor gesehen haben. Das sind Dinge, die wir in unseren Diagrammen niedergezogen haben. Wenn Sie die relative Größe jeder Ebene bemerkt haben, können Sie beginnen zu verstehen, woher der Großteil des Projekts stammt. Zum Beispiel ist hier die generische Ebene eher klein. Wir haben nicht wirklich viel hier drin, wir haben unsere globale Box-Dimensionierung, einige normalisieren und zurücksetzen Art von Stilen und einige gemeinsame Stile auch. Aber schauen wir uns die Elementebene an. Wir können sehen, dass wir noch ein paar Dateien haben, die anfangen, ein wenig größer zu werden. Hier unterzeichnen wir Dinge wie Überschriften, Links und Listen. Dies sind die HTML-Elemente, aus denen unsere Seite besteht. Darüber hinaus bewegen wir uns auf unsere Objekte-Layer. Der Objekte-Layer ist die erste Ebene, in der wir Klassen einführen dürfen. Dies ist wieder etwas größer als die Elementschicht, aber wenn wir zur Komponentenschicht gelangen, sehen wir, dass die Dinge bei weitem, viel größer sind. Die Komponentenschicht macht den Großteil eines bestimmten Projekts aus. Die Mehrheit Ihrer Website wird komponentenbasiert sein, ITCSS unterstützt dies durch die Erstellung eines ganzen Teils des Projekts für all diese Dinge live. Was Sie sehen werden, sind konsistente Namen, components.logo, components.masthead. Es ist in diesen Dateien, die wir die Mehrheit unserer UI finden. Schließlich gehen wir in Richtung unserer Dienstprogramme Schicht und es ist an dieser Stelle importieren wir jede Art von Debugging-Dateien oder irgendwelche Dienstprogramme und Art von Hilfsklassen. Es ist an diesem Punkt, dass wir spezifische IE 7-Fixierer oder verschiedene Fixierer für verschiedene Browser einbringen können . Utilities Layer ist für CSS reserviert, die nicht ganz perfekt ist. Es ist für CSS reserviert, die ziemlich hohe Spezifität ist, oft sogar Bedeutung enthält. Wir werden uns das in Kürze genauer ansehen. diese Datei betrachten, sollten wir hoffentlich sehen, dass selbst ein ziemlich großes Projekt in sehr überschaubare Stücke destilliert werden kann. Wir können schnell sehen, was genau wohin und warum lebt. Dies bedeutet, dass die Suche nach vorhandenem CSS trivial wird und es bedeutet, dass das Hinzufügen neuer CSS ziemlich einfach und unkompliziert werden sollte. Indem wir uns die Muster ansehen, die von einem früheren Entwickler hinterlassen wurden, können wir dort aufheben, wo sie aufgehört haben, und eine viel konsistentere Codebasis erstellen. Wie Sie aus der aktuellen Datei sehen können, die wir uns ansehen, hat es derzeit alle Standard-ITCSS verwandt. Bestimmte Projekte erfordern jedoch möglicherweise unterschiedliche Ebenen oder das Entfernen bestimmter Ebenen. ITCSS überlässt dies ganz uns. Also, das war ein echter kurzer Blick darauf, wie das Dreieck in einem importierten SAS-Bundle zusammenkommen kann . Abhängig von Ihrem Projekt, Ihrem Umstand, Ihrem Build-Prozess, Ihrer Build-Pipeline können sich die Besonderheiten unterscheiden und die Schönheit von ITCSS liegt ganz bei Ihnen, wie Sie diesen Workflow ändern. Was ich Ihnen als nächstes zeigen möchte, ist jedoch die resultierende SCC-Datei. Alle Diagramme, die wir zuvor gezeichnet wurden, waren von Zeile 0-3.000, ist, was wir verwendet, sie wurden komplette kompilieren Stylesheets dargestellt. Schauen wir uns an, wie sich das ergibt. Sehen wir uns nun an, wie das alles zusammenkommt, sobald es in einem großen Stylesheet zusammengestellt wurde . Unmittelbar hier werden wir, dass wir ein vertrautes Inhaltsverzeichnis haben, das von unserem Haupteinstiegspunkt, unserer main.scss-Datei, übernommen wurde. Wenn wir das vorbeiziehen, werden wir anfangen, etwas natürliches SCSS zu sehen. Nun, denken Sie daran, die drei Kernprinzipien des Dreiecks, niedrige Spezifität in Richtung hoher Spezifität, unexplizit in Richtung explizit und weit bis hin zu schmaler Reichweite. Also, sofort können wir hier sehr geringe Spezifität sehen. Sie haben einen Stern-Selektor, wir haben den HTML-Element-Selektor, sind sehr niedrige Spezifitäts-Selektoren, die ein sehr breites Netz werfen. Der Stern-Selektor erfasst buchstäblich alles im DOM. Also, als wir das durchgemacht haben, und ich werde das relativ schnell tun, was Sie sehen sollten, ist die Spezifitätsgrafik, die sich vor Ihren Augen bildet. Während wir durch niedrige Spezifität Elementselektoren wirbeln, nächstes sollten wir beginnen, einige Klassenselektoren erscheinen zu sehen , wenn wir zu Objekten kommen. Hier haben wir 0-Layout, also haben wir diese sofortige Spezifität Bump in unsere Objekte-Layer, die erste Ebene, in der wir Klassen sehen dürfen. Was Sie hier bemerken, ist, dass diese Klassen mit einem o-. Nun, dies ist eine optionale Namenskonvention, die mit ITCSS geliefert wird. Von hier aus finden wir mehr Klassen, so dass wir keine Erhöhung der Spezifität bekommen, aber wir bekommen eine Änderung des Zwecks. Hier müssen wir c- was unsere Komponentenklassen bezeichnet. Komponenten sind die Bits, die den Großteil der Benutzeroberfläche ausmachen, und hier sehen wir, dass es eine Bamm-ähnliche Namenskonvention verwendet. Wenn wir über die Komponentenklassen hinausgehen, werden wir anfangen, sehr, sehr hohe Spezifitätsklassen zu finden . Dies ist, wo wir zu unserer Dienstprogrammschicht gelangen. Dienstprogramme Schicht ist ein Sonderfall. Es ist für alle Arten von CSS reserviert, von denen wir nicht besonders begeistert sind. Bei großen Projekten ist es garantiert, dass es passieren wird, dass Sie etwas CSS beisteuern müssen, das nicht ganz so ist, wie Sie möchten. Nun, das ist nicht ideal. Natürlich ist es nicht ideal, aber es wird wahrscheinlich passieren, es ist bei jedem Projekt passiert, an dem ich je gearbeitet habe. Also, was ziemlich wichtig ist, ist, einen dedizierten Platz für diese Bits von CSS zu haben , die unsere Dienstprogramme Schicht leben, wird zu einem Catchall, einer Verschiedenen Schublade, die alle CSS erfasst, die nirgendwo anders passt. Es gegen Ende zu lassen bedeutet, dass es nicht riskiert, den Ton für den Rest des Projekts festzulegen. Sie möchten Ihr hacky CSS nicht am Anfang Ihres Stylesheets aufrufen da dies bedeuten würde, dass der Rest des Stylesheets darum kämpfen muss. Wir zeichnen all das Zeug direkt am Ende, so dass es sofort alles überschreiben kann, was vorher mit sehr minimalem Overhead kam. Während wir bis zum Ende des Stylesheets vorankamen, werden wir feststellen, dass die Dinge dort enden. Wir enden auf eine sehr hohe Spezifität mit einigen sehr, sehr gezielten Single-Use-Case-Klassen. Dies sind Utility-Klassen, die entworfen wurden, um alles, was zuvor mit minimalem Aufwand kam, zu überschreiben . Nun, ich möchte Sie dringend bitten, dieses Repository absolut zu erkunden , denn wenn Sie anfangen, es auseinander zu nehmen, werden Sie bald feststellen, dass alle Dinge, die wir besprochen haben, sofort an Ort und Stelle sitzen, werden Sie feststellen, dass die Dinge viel mehr Sinn machen. Sie werden in der Lage sein, die Codebasis sehr schnell zu navigieren , basierend auf den konzeptionellen Dingen, die wir zuvor gelernt haben. Nun, natürlich, das war nur eine Demonstration, um der Demonstration willen. Es war eine sehr kleine, sehr eigenständige Demo. Es ist nicht unbedingt so realistisch von einer großen Art von Tier eines Projekts. Also, was Sie feststellen werden, ist, dass, wenn Sie ITCSS in der realen Welt implementieren, die Vorteile deutlich deutlicher werden, selbst in diesem verkürzten Beispiel hoffentlich erfahren wir , dass wir , indem wir die drei Kernprinzipien von ITCSS können wir damit beginnen, Dinge gewidmet Orte zu leben und gewidmet Orte zu finden. Was das bedeutet, ist, wenn ein Entwickler, der in ein Projekt Fallschirmspringen kann, sich leicht selbst lokalisieren und leicht durch die Codebasis navigieren kann, die sie möglicherweise noch nie zuvor gesehen haben. 7. Letzte Gedanken: Also, da haben wir es, eine Einführung in die Inverted Triangle CSS-Architektur. Wir haben gelernt, wie CSS, wenn es seinen eigenen Geräten überlassen wird, schnell widerspenstig und schwer zu verwalten werden kann. Aber dann haben wir auch gelernt, dass wir mit viel Fleiß und etwas Formalität diese Dinge leicht wieder einschreiben und ihnen helfen können, zu unserem Vorteil zu arbeiten. Vor allem möchte ich, dass die Leute davon wegnehmen, ist die Tatsache, dass ITCSS kein komplexes System ist, es erfordert keine drastischen Veränderungen in Prozess oder Form. Darüber hinaus ist es eine sehr leichte Berührung. So können Sie ITCSS an Ihren Technologie-Stack anpassen, Fähigkeiten in Ihrem Team, die Größe Ihres Projekts und sogar die Art des Projekts, das Sie gerade bearbeiten. Auf technischer Ebene denke ich, dass mein Schlüssel zum Mitnehmen für Sie wäre, bin wirklich wirklich wirklich wichtig, Dinge wie Spezifität sehr gut zu verwalten, weil dies normalerweise die technische Art und Weise ist, in der Projekte beginnen, die am schnellsten. Also, was als nächstes? Nun, das erste, was Sie tun könnten, ist, an der Diskussion teilzunehmen. Wenn Sie Fragen, Bedenken, Beispiele oder Downloads haben , die Sie besprechen oder im Freien gehen möchten, gehen Sie absolut und tun Sie das. Ich werde dort im Auge behalten und alle Fragen beantworten, die Sie haben. Natürlich, behalten Sie ein Auge auf die Ressourcen Abschnitte, eine Reihe von Links zu den verschiedenen Lesematerialien und behalten Sie das im Auge. Es gibt jede Menge Zeug zu sehen. Also, das war es. Vielen Dank, dass du rumgehst. Ich freue mich sehr darauf, zu sehen, wie Sie ITCSS nehmen , in Ihr eigenes Projekt und Ihre eigene Arbeit einfließen, und ich schätze, wir sehen uns nächstes Mal.