Warum sollten Sie SCSS anstelle von Styled Components verwenden?

Nach einem Vergleich gängiger Lösungen wie einfaches CSS, Emotion, SCSS und Gestaltete Komponentenwählte ich schließlich die letzte aus. Alles schien in Ordnung zu sein. Es hat eine sehr beliebte Bibliothek heutzutage, was bedeutet
Es gibt bereits eine große Community, wenn ich also auf Probleme stoße, finde ich wahrscheinlich irgendwo auf Stack Overflow oder GitHub eine Lösung. Abgesehen davon, Gestaltete Komponenten verfügen über einige Optimierungsfunktionen, d. h. sie werden nur dann gerendert, wenn sie benötigt werden. Die Projekt sollte mit React und Typescript erstellt werden. Diese Bibliothek bietet großartige Unterstützung für beide Technologien. Klingt großartig, oder?

Dann habe ich angefangen zu programmieren. Nach einem Monat, als die App gewachsen war, wurde das Frontend Team und ich auf die Bereitstellung von Funktionen konzentrierten, fanden wir heraus, dass die erstaunlichen Gestaltete Komponenten Die Bibliothek hatte ein Eigentor geschossen, und ich werde Ihnen sagen, warum.

Zunächst einmal die Namenskonvention. Zur Unterscheidung Gestaltete Komponenten aus React-Komponenten, musste ich die Gestaltet Präfix, das die Code Lesbarkeit. Dann (was seltsam sein könnte), Typescript-Unterstützung. Gestaltete Komponentenbasieren, wie Sie vielleicht wissen, auf dem CSS-in-JS-Ansatz. Das heißt, man kann ihnen eine beliebige Requisite übergeben und den Stil der Eingabe basierend auf dieser Requisite ändern, und ich persönlich finde diese Funktion großartig. In Typescript sollte man auch den Typ dieser Requisite implementieren, damit der Code länger wird. Gestaltete Komponente. "Aber es würde doch nur 5 Sekunden länger dauern, wo liegt also das Problem", werden Sie vielleicht sagen. Sie haben Recht, obwohl, wenn die App schnell skaliert und die Anzahl der Komponenten ist
Mit zunehmender Dauer können diese 5 Sekunden leicht um das Hundertfache vervielfacht werden. Ein weiteres Problem ist die Platzierung der Gestaltete Komponenten.

Einige JS-Entwickler platzieren sie in derselben Datei wie die Komponente, zu der sie gehören, und andere erstellen separate Dateien für sie. Beide Ansätze sind aus vielen Gründen gut. Es hängt hauptsächlich von der Komplexität der Komponente ab. Wenn man eine dieser Techniken anwendet, kann man die Kohäsion aufrechterhalten, aber wenn man sie zusammenführt, erreicht man genau das Gegenteil. Wir haben uns von dem CSS-in-JS-Ansatz verabschiedet und sind zu SCSS. Es war nicht einfach und schnell, aber mit ein wenig Hilfe haben wir es geschafft. Wir begannen mit dem Styling von HTML-Tags in der BEM-Methodik und legten natürlich Stile in separaten Dateien ab, eine pro Komponente. Ich sagte, dass die Übergabe von JS-Props an Gestaltete Komponenten ist eine großartige Funktion, aber in SCSS das ist unmöglich. Ich denke, wir sind uns auch alle einig, dass die Syntax, die React für die Kodierung bedingter Klassen verwenden will, schrecklich ist.

Nun, es gibt eine recht interessante Lösung. Wenn Sie die BEM-Methodik mit der clsx Bibliothek, erhalten Sie etwas wie dieses (ein großes Lob an meinen Freund Przemek Adamczyk, der mir diese Bibliothek gezeigt hat)

Sieht viel sauberer aus, finden Sie nicht auch?

Das Beste ist, dass Sie nur die Bedingungsvariable auf der Komponentenebene eingeben müssen und
nicht auf der Ebene des Stylings. Das spart wirklich Zeit. Leider hat eine solche Lösung auch ihre Nachteile.
SCSS ist einfach und freundlich, aber seien Sie vorsichtig, wenn Sie es mit Next.js verwenden. Dieses Framework bietet keine
erlauben es, Stildateien direkt in die Komponentendatei zu importieren (nur CSS-Module).

Wenn Sie eine Datei pro Komponente bevorzugen, müssen Sie eine index.scss mit all Ihren SCSS Dateien und
importieren sie in die _app.tsx Datei. Das einzige Problem ist, dass Sie jede Datei manuell importieren müssen. SCSS Datei, die Sie erstellt haben. In React gibt es dieses Problem jedoch nicht, und Sie können Folgendes importieren SCSS Dateien, wo immer Sie wollen. Verstehen Sie mich nicht falsch. Gestaltete Komponenten sind wirklich gut. Wie ich bereits sagte, sind die Übergabe von JS-Variablen sowie das globale Thema erstaunliche Funktionen. Wenn Sie eine große App bauen, bei der Optimierung entscheidend ist, wird diese Bibliothek wahrscheinlich Ihre Bedürfnisse erfüllen. In unserem Fall jedoch ist die Migration zu SCSS den Jackpot zu knacken.

Resümee

Zusammenfassend lässt sich sagen, dass es zwar stichhaltige Argumente für beide SCSS und gestaltete Komponenten in Web-Entwicklung Die endgültige Entscheidung hängt von verschiedenen Faktoren ab. SCSS bietet eine vertrautere Syntax für erfahrene Entwickler in traditionellem CSS und bietet eine nahtlose Integration mit bestehenden Code-Basen und Komponentenbibliotheken .

Andererseits, Gestaltete Komponenten erweitertes Angebot Entwicklererfahrung mit seiner Fähigkeit, Stile in Komponenten zu kapseln und den Styling-Prozess zu vereinfachen. Außerdem fördert es die Modularität und Wiederverwendbarkeit des Codes und ermöglicht Front-End-Ingenieuren die effiziente Verwaltung der Komponentenverzeichnis und eine konsistente Benutzeroberfläche für die Web-Applikation . In Anbetracht der Bedeutung der Benutzerdaten Sicherheit und Leistung zu gewährleisten, ist es von entscheidender Bedeutung, die Auswirkungen beider Ansätze auf die endgültige Paketgröße und die Ladezeiten zu bewerten. Letztlich ist die Wahl zwischen SCSS und gestaltete Komponenten sollte auf den spezifischen Bedürfnissen des Projekts und den Fähigkeiten der Mitarbeiter beruhen. Entwicklungsteam und die allgemeinen Ziele des Webanwendung . Für Entwickler ist es ratsam, alle Faktoren zu bewerten, sich durch Blogeinträge und Branchendiskussionen zu informieren und eine fundierte Entscheidung zu treffen, die den Anforderungen des Projekts entspricht und das Gesamtbild verbessert. Frontend-Entwicklungsprozess .