Share
Heeft u zich ooit afgevraagd hoe een grote site als Tuts + zijn CSS, HTML en JavaScript op orde houdt ten opzichte van voortdurende ontwikkeling en iteratie? Ik ga je het proces laten zien dat we hebben geïmplementeerd om het allemaal netjes en onderhoudbaar te houden.
De eerste stap in dit proces was het vinden van een manier om de grote hoeveelheid CSS die we nodig hebben te bouwen die niet onvermijdelijk in chaos zal eindigen..
Traditioneel met CSS bouw je stijlen op zoals je ze nodig hebt en probeer je selectors breed toepasbaar te maken zodat ze overal op de site kunnen worden hergebruikt. Hier volgen bijvoorbeeld enkele eenvoudige CSS-regels die niet misstaan in de meeste stylesheets:
h1 font-size: 22px; .subtitle font-size: 18px;
Als u deze selectors op een specifiek gedeelte van een pagina moet negeren, kunt u geneste regels gebruiken om selectors te maken die specifiekere elementen targeten:
.site-header h1 font-size: 40px; .site-header .subtitle font-size: 28px; .site-header a.navigation color: # 136FD2 ...
Deze benadering voelt intuïtief correct, maar het kan een aantal belangrijke problemen hebben als je eenmaal op een site bent die meer dan een paar pagina's heeft en waaraan meer dan één ontwikkelaar werkt.
Wat gebeurt er wanneer we de vormgeving van wijzigen h1 of .subtitel op een wereldwijd niveau? lettertypegrootte wordt al overschreven door een meer specifieke stijl, maar als we er een toevoegen lettertype dikte of lijnhoogte dat zal het niet zijn. Alle wijzigingen die in de globale stijlen worden aangebracht, kunnen naar voren komen en meer specifieke stijlen beïnvloeden op manieren die niet voorspelbaar zijn zonder een grondige kennis van alle stijlen op de site..
Hoe meer stijlen op deze manier worden gebouwd, des te meer uitgesproken de "bijwerkingen" van interactieve CSS-stijlen zullen zijn, vervelend trial-and-error om recht te zetten, en uiteindelijk resulteren in een verlies van productiviteit en meer bugs die door de productie kruipen..
Om dit probleem te helpen voorkomen, hebben we een benadering van CSS toegepast op basis van de BEM-methodologie. In plaats van stijlen te definiëren die globaal van toepassing zijn, worden alle stijlen door middel van een naamgevingsconventie tot zelfstandige 'blokken' ingesloten. Een "blok" is min of meer gedefinieerd als een enkele vrijstaande eenheid van inhoud die potentieel herbruikbaar is (hoewel het niet verplicht is dat deze daadwerkelijk opnieuw wordt gebruikt).
Laten we bijvoorbeeld het blok met aanbevolen items bekijken:
Volgens onze naamgevingsconventie heeft dit blok een root div element met de klassenaam gekenmerkt-secties. Het bevat elementen met klassennamen zoals Aanbevolen-sections__title en gekenmerkte-sections__section-koppeling.
We gebruiken een overeenkomende naamgevingsconventie voor onze broncode, als zodanig alle stijlen hiervoor Aanbevolen-sectie blok wordt opgeslagen in modules / featured_section.sass:
.featured-sections marge: 0 0 $ goot-breedte 0 padding-top: 8px border-top: 4px solid # dae1e5 .featured-sections__title color: # 8fa6b3 font: bold 14px / 1.2em $ font
Deze naamconventie zorgt ervoor dat stijlen niet langer conflicteren en vermengen. Zolang onze naamgevingsconventie wordt gevolgd, met de bloknaam aan het begin van elke klassennaam, is het onmogelijk dat een stijl iets beïnvloedt buiten zijn eigen blok..
Het maakt het ook super gemakkelijk om uit te vinden waar te kijken in de codebase voor de stijlen die overeenkomen met een element. U kunt eenvoudig naar de klassenaam van het element kijken en u zult de naam van het stylesheet weten om te openen.
We hebben ervoor gekozen om verder te gaan en deze naamgevingsconventie ook in onze standpunten toe te passen. Elk blok heeft een gedeeltelijke weergave met dezelfde naam, opgeslagen onder views / modules. Bijvoorbeeld de HTML-weergave voor onze gekenmerkt-secties levens blokkeren views / modules / _featured_sections.html.slim:
Op dezelfde manier dat het hebben van een naamgevingsconventie voor onze CSS-bestanden het gemakkelijk maakt om een CSS-stijl te vinden, omdat het hebben van deze naamconventie voor onze weergaven het gemakkelijk maakt om weergavecode te vinden. Dit is handig wanneer u een pagina in een browser bekijkt en een specifiek onderdeel opmerkt dat enkele wijzigingen nodig heeft. U kunt gewoon een "Inspect Element" uitvoeren en de bloknaam gebruiken die duidelijk zichtbaar is in de CSS-klasse van een element, zodat u meteen naar het relevante viewbestand kunt springen..
We zijn ook doorgegaan en hebben dezelfde naamgevingsconventies voor onze JavaScript-code aangenomen, met een beetje hulp van Backbone.js.
Elk blok waarvoor JavaScript-gedrag is toegepast, krijgt een Backbone-weergaveobject met dezelfde bloknaam:
Accentsconagua
class window.AccountHeader breidt Backbone.View-evenementen uit: 'change .account-header__mobile-menu-select': 'mobileMenuChange' mobileMenuChange: -> document.location = @_selectedOption (). data ('url') _selectedOption: -> @ $ 'optie: geselecteerd'We hebben een aantal laadcode voor bekijken geschreven die wordt toegepast bij het laden van de pagina, zodat de juiste Backbone-weergave automatisch wordt geladen voor elk element met een CSS-klasse die overeenkomt met een lijst met blokkennamen met bijbehorende JS.
We gebruiken dezelfde bestandsnaamconventie voor onze JavaScript-code, wat resulteert in de structuur voor een volledig uitgelicht blok dat er als volgt uitziet:
Ik zou deze aanpak ten zeerste aanbevelen voor elk project. Ik denk dat het van onschatbare waarde is bij het werken aan een groot project, en zelfs als je op een veel kleinere site werkt, is er echt geen nadeel om je front-end code op een modulaire manier te structureren..
Dat gezegd hebbende, kunt u problemen ondervinden bij het gebruik van deze strategie als u al een aanzienlijk aantal algemene CSS-stijlen hebt of als u afhankelijk bent van CSS-bibliotheken zoals Twitter Bootstrap. Aangezien BEM-stijlen een enkele klassenaam als hun selector gebruiken, hebben ze een zeer lage CSS-specificiteitswaarde en worden ze vaak vertrapt door globale CSS-stijlen die vaak meerdere niveaus van geneste selectoren hebben, evenals tagnamen en ID's.
Het is absoluut nog steeds mogelijk om van een globale CSS-stijl naar een meer modulaire BEM-stijl te gaan, en ik zou het op de lange termijn zeker waard zijn. Verwacht echter dat het iets moeilijker is om je BEM-stijlen een tijdje te bouwen en wees bereid om te leven met het toevoegen van een paar tijdelijke !belangrijk declaraties in uw CSS, totdat u zich volledig kunt ontdoen van uw globale stijlen.
