CSS @apply -sääntö: Natiivien mixinien nousu ja tuho sekä modernit vaihtoehdot

Jatkuvasti kehittyvässä web-kehityksen maailmassa pyrkimys puhtaampaan, ylläpidettävämpään ja uudelleenkäytettävämpään koodiin on alituinen. Vuosien ajan kehittäjät ovat turvautuneet CSS-esikääntäjiin, kuten Sassiin ja Lessiin, tuodakseen ohjelmallista voimaa tyylitiedostoihin. Yksi näiden työkalujen rakastetuimmista ominaisuuksista on mixin – tapa määritellä uudelleenkäytettävä lohko CSS-määrityksiä. Tämä johti luonnolliseen kysymykseen: voisimmeko saada tämän tehokkaan ominaisuuden natiivisti CSS:ään? Hetken aikaa vastaus näytti olevan kyllä, ja sen nimi oli @apply.

@apply-sääntö oli lupaava ehdotus, jonka tavoitteena oli tuoda mixinien kaltainen toiminnallisuus suoraan selaimeen hyödyntäen CSS Custom Properties -ominaisuuden tehoa. Se lupasi tulevaisuuden, jossa voisimme määritellä uudelleenkäytettäviä tyylinpätkiä puhtaalla CSS:llä ja soveltaa niitä missä tahansa, jopa päivittäen niitä dynaamisesti JavaScriptillä. Kuitenkin, jos olet kehittäjä tänään, et löydä @apply-sääntöä mistään vakaasta selaimesta. Ehdotus vedettiin lopulta pois virallisesta CSS-määrittelystä.

Tämä artikkeli on kattava tutkimusmatka CSS:n @apply-sääntöön. Käymme läpi, mikä se oli, sen tarjoaman valtavan potentiaalin tyylien koostamisessa, sen vanhentumisen monimutkaiset syyt ja, mikä tärkeintä, modernit, tuotantovalmiit vaihtoehdot, jotka ratkaisevat samat ongelmat nykypäivän kehitysekosysteemissä.

Mikä oli CSS @apply -sääntö?

Ytimessään @apply-sääntö oli suunniteltu ottamaan joukko CSS-määrityksiä, jotka oli tallennettu custom-ominaisuuteen, ja "soveltamaan" niitä CSS-säännön sisällä. Tämä antoi kehittäjille mahdollisuuden luoda niin sanottuja "ominaisuuspussukoita" tai "sääntöjoukkoja", joita voitiin käyttää uudelleen useissa valitsimissa, noudattaen Don't Repeat Yourself (DRY) -periaatetta.

Konsepti perustui CSS Custom Properties -ominaisuuteen (usein kutsutaan CSS-muuttujiksi). Vaikka yleensä käytämme custom-ominaisuuksia yksittäisten arvojen, kuten värin (--brand-color: #3498db;) tai koon (--font-size-md: 16px;), tallentamiseen, @apply-ehdotus laajensi niiden kykyä sisältää kokonaisia määrityslohkoja.

Ehdotettu syntaksi

Syntaksi oli suoraviivainen ja intuitiivinen kaikille CSS:ää tunteville. Ensin määrittelisit custom-ominaisuuden, joka sisältää lohkon CSS-määrityksiä aaltosulkeiden {} sisällä.

            
:root {
  --primary-button-styles: {
    background-color: #007bff;
    color: #ffffff;
    border: 1px solid transparent;
    padding: 0.5rem 1rem;
    font-size: 1rem;
    border-radius: 0.25rem;
    cursor: pointer;
    transition: background-color 0.2s ease-in-out;
  };
}

            

              
                Copy
              
            
          

Sitten missä tahansa CSS-säännössä voisit käyttää @apply-at-sääntöä lisätäksesi koko tyylilohkon:

            
.btn-primary {
  @apply --primary-button-styles;
}

.form-submit-button {
  @apply --primary-button-styles;
  margin-top: 1rem; /* Voit silti lisätä muita tyylejä */
}

            

              
                Copy
              
            
          

Tässä esimerkissä sekä .btn-primary että .form-submit-button perisivät koko --primary-button-styles-muuttujassa määritellyn tyylijoukon. Tämä oli merkittävä poikkeama standardista var()-funktiosta, joka voi korvata vain yhden arvon yhdessä ominaisuudessa.

Tärkeimmät aiotut hyödyt

• Koodin uudelleenkäytettävyys: Ilmeisin hyöty oli toiston poistaminen. Yleisiä malleja, kuten painikkeiden tyylejä, korttiasetteluja tai hälytyslaatikoita, voitiin määritellä kerran ja soveltaa kaikkialla.
• Parempi ylläpidettävyys: Kaikkien pääpainikkeiden ulkoasun päivittämiseksi sinun tarvitsisi muokata vain --primary-button-styles-custom-ominaisuutta. Muutos leviäisi sitten jokaiseen elementtiin, jossa sitä käytettiin.
• Dynaaminen teemoitus: Koska se perustui custom-ominaisuuksiin, näitä mixinejä voitiin muuttaa dynaamisesti JavaScriptillä, mikä mahdollisti tehokkaat ajonaikaiset teemoitusmahdollisuudet, joita esikääntäjät (jotka toimivat käännösaikana) eivät voi tarjota.
• Kuromassa kuilua umpeen: Se lupasi tuoda esikääntäjämaailmasta rakastetun ominaisuuden natiiviin CSS:ään, vähentäen riippuvuutta käännöstyökaluista tämän nimenomaisen toiminnallisuuden osalta.

@applyn lupaus: Natiivit mixinit ja tyylien koostaminen

@applyn potentiaali ulottui paljon yksinkertaista tyylien uudelleenkäyttöä pidemmälle. Se avasi kaksi tehokasta konseptia CSS-arkkitehtuurille: natiivit mixinit ja deklaratiivisen tyylien koostamisen.

Natiivi vastaus esikääntäjien mixineille

Vuosien ajan Sass on ollut mixinien kultainen standardi. Verrataanpa, miten Sass saavuttaa tämän siihen, miten @applyn oli tarkoitus toimia.

Tyypillinen Sass-mixin:

            
@mixin flexible-center {
  display: flex;
  justify-content: center;
  align-items: center;
}

.hero-banner {
  @include flexible-center;
  height: 100vh;
}

.modal-content {
  @include flexible-center;
  flex-direction: column;
}

            

              
                Copy
              
            
          

Vastaava @applylla:

            
:root {
  --flexible-center: {
    display: flex;
    justify-content: center;
    align-items: center;
  };
}

.hero-banner {
  @apply --flexible-center;
  height: 100vh;
}

.modal-content {
  @apply --flexible-center;
  flex-direction: column;
}

            

              
                Copy
              
            
          

Syntaksi ja kehittäjäkokemus olivat huomattavan samankaltaisia. Avainero oli kuitenkin toteutuksessa. Sass @mixin käsitellään käännösvaiheessa, tuottaen staattista CSS:ää. @apply-säännön olisi käsitellyt selain ajon aikana. Tämä ero oli sekä sen suurin vahvuus että, kuten tulemme näkemään, sen lopullinen tuho.

Deklaratiivinen tyylien koostaminen

@apply olisi mahdollistanut kehittäjille monimutkaisten komponenttien rakentamisen koostamalla pienempiä, yksikäyttöisiä tyylinpätkiä. Kuvittele rakentavasi käyttöliittymäkomponenttikirjastoa, jossa sinulla on peruspalikoita typografialle, asettelulle ja ulkoasulle.

            
:root {
  --typography-body: {
    font-family: 'Inter', sans-serif;
    font-size: 16px;
    line-height: 1.5;
    color: #333;
  };

  --card-layout: {
    padding: 1.5rem;
    border-radius: 8px;
    box-shadow: 0 4px 8px rgba(0,0,0,0.1);
  };

  --theme-light: {
    background-color: #ffffff;
    border: 1px solid #ddd;
  };

  --theme-dark: {
    background-color: #2c3e50;
    border: 1px solid #444;
    color: #ecf0f1;
  };
}

.article-card {
  @apply --typography-body;
  @apply --card-layout;
  @apply --theme-light;
}

.user-profile-card.dark-mode {
  @apply --typography-body;
  @apply --card-layout;
  @apply --theme-dark;
}

            

              
                Copy
              
            
          

Tämä lähestymistapa on erittäin deklaratiivinen. .article-card-luokan CSS ilmaisee selvästi sen koostumuksen: siinä on leipätekstin typografia, korttiasettelu ja vaalea teema. Tämä tekee koodista helpommin luettavaa ja ymmärrettävää.

Dynaaminen supervoima

Kaikkein vakuuttavin ominaisuus oli sen ajonaikainen dynaamisuus. Koska --card-theme voisi olla tavallinen custom-ominaisuus, voisit vaihtaa kokonaisia sääntöjoukkoja JavaScriptillä.

            
/* CSS */
.user-profile-card {
  @apply --typography-body;
  @apply --card-layout;
  @apply var(--card-theme, --theme-light); /* Sovelletaan teema, oletuksena vaalea */
}

/* JavaScript */
const themeToggleButton = document.getElementById('theme-toggle');
themeToggleButton.addEventListener('click', () => {
  const root = document.documentElement;
  const isDarkMode = root.style.getPropertyValue('--card-theme') === '--theme-dark';

  if (isDarkMode) {
    root.style.setProperty('--card-theme', '--theme-light');
  } else {
    root.style.setProperty('--card-theme', '--theme-dark');
  }
});

            

              
                Copy
              
            
          

Tämä hypoteettinen esimerkki näyttää, kuinka voisit vaihtaa komponentin vaalean ja tumman teeman välillä muuttamalla yhtä ainoaa custom-ominaisuutta. Selaimen olisi sitten arvioitava @apply-sääntö uudelleen ja vaihdettava suuri joukko tyylejä lennosta. Tämä oli uskomattoman voimakas idea, mutta se myös vihjasi pinnan alla kuplivasta valtavasta monimutkaisuudesta.

Suuri väittely: Miksi @apply poistettiin CSS-määrittelystä?

Miksi @apply katosi, vaikka sillä oli niin vakuuttava visio? Päätöstä sen poistamisesta ei tehty kevyesti. Se oli tulosta pitkistä ja monimutkaisista keskusteluista CSS Working Groupissa (CSSWG) ja selainvalmistajien kesken. Syyt tiivistyivät merkittäviin ongelmiin suorituskyvyn, monimutkaisuuden ja CSS:n perusperiaatteiden kanssa.

1. Hyväksymättömät suorituskykyvaikutukset

Tämä oli sen tuhon ensisijainen syy. CSS on suunniteltu olemaan uskomattoman nopea ja tehokas. Selaimen renderöintimoottori voi jäsentää tyylitiedostoja, rakentaa CSSOM:n (CSS Object Model) ja soveltaa tyylejä DOM:iin erittäin optimoidussa järjestyksessä. @apply-sääntö uhkasi murskata nämä optimoinnit.

• Jäsentäminen ja validointi: Kun selain kohtaa custom-ominaisuuden kuten --main-color: blue;, sen ei tarvitse validoida arvoa `blue` ennen kuin sitä käytetään ominaisuudessa kuten `color: var(--main-color);`. Kuitenkin @applyn kanssa selaimen olisi pitänyt jäsentää ja validoida kokonainen lohko mielivaltaisia CSS-määrityksiä custom-ominaisuuden sisällä. Tämä on paljon raskaampi tehtävä.
• Kaskadin monimutkaisuus: Suurin haaste oli selvittää, miten @apply toimisi yhdessä kaskadin kanssa. Kun @apply-säännöllä sovelletaan tyylilohkoa, mihin kohtaan kaskadia ne tyylit sijoittuvat? Onko niillä sama spesifisyys kuin säännöllä, jossa ne ovat? Mitä tapahtuu, jos @applylla sovellettu ominaisuus myöhemmin ylikirjoitetaan toisella tyylillä? Tämä loi "myöhään rikkoutuvan" kaskadiongelman, joka oli laskennallisesti kallis ja vaikea määritellä johdonmukaisesti.
• Ikuiset silmukat ja sykliset riippuvuudet: Se toi mukanaan mahdollisuuden syklisille viittauksille. Mitä jos --mixin-a soveltaisi --mixin-b:tä, joka puolestaan soveltaisi --mixin-a:ta? Näiden tapausten havaitseminen ja käsittely ajon aikana lisäisi merkittävää yleiskustannusta CSS-moottoriin.

Pohjimmiltaan @apply vaati selainta tekemään merkittävän määrän työtä, joka normaalisti hoidetaan käännöstyökaluilla käännösaikana. Tämän työn tehokas suorittaminen ajon aikana jokaisen tyylin uudelleenlaskennan yhteydessä katsottiin liian kalliiksi suorituskyvyn näkökulmasta.

2. Kaskadin takuiden rikkominen

CSS-kaskadi on ennustettava, vaikkakin joskus monimutkainen järjestelmä. Kehittäjät luottavat sen spesifisyyden, periytymisen ja lähdejärjestyksen sääntöihin pystyäkseen päättelemään tyyliensä käyttäytymistä. @apply-sääntö toi mukanaan epäsuoruuden tason, joka teki tästä päättelystä paljon vaikeampaa.

Harkitse tätä skenaariota:

            
:root {
  --my-mixin: {
    color: blue;
  };
}

div {
  @apply --my-mixin; /* väri on sininen */
  color: red;        /* väri on nyt punainen */
}

            

              
                Copy
              
            
          

Tämä näyttää riittävän yksinkertaiselta. Mutta entä jos järjestys olisi päinvastainen?

            
div {
  color: red;
  @apply --my-mixin; /* Ylikirjoittaako tämä punaisen? */
}

            

              
                Copy
              
            
          

CSSWG:n oli päätettävä: toimiiko @apply kuten lyhenneominaisuus, joka laajenee paikalleen, vai toimiiko se kuin joukko määrityksiä, jotka lisätään omalla lähdejärjestyksellään? Tämä epäselvyys heikensi CSS:n ydintä, ennustettavuutta. Sitä kuvailtiin usein "magiaksi" – termi, jota kehittäjät käyttävät käyttäytymisestä, jota ei ole helppo ymmärtää tai debugata. Tällaisen magian tuominen CSS:n ytimeen oli merkittävä filosofinen huolenaihe.

3. Syntaksin ja jäsentämisen haasteet

Syntaksi itsessään, vaikka se vaikutti yksinkertaiselta, aiheutti ongelmia. Mielivaltaisen CSS:n salliminen custom-ominaisuuden arvon sisällä tarkoitti, että CSS-jäsentimen olisi pitänyt olla paljon monimutkaisempi. Sen olisi pitänyt käsitellä sisäkkäisiä lohkoja, kommentteja ja mahdollisia virheitä itse ominaisuuden määrittelyssä, mikä oli merkittävä poikkeama siitä, miten custom-ominaisuudet oli suunniteltu toimimaan (pitäen sisällään käytännössä merkkijonon korvaamiseen asti).

Lopulta yksimielisyys oli, että suorituskyky- ja monimutkaisuus-kustannukset ylittivät reilusti kehittäjien saaman hyödyn, varsinkin kun muita ratkaisuja oli jo olemassa tai tulossa.

@applyn perintö: Modernit vaihtoehdot ja parhaat käytännöt

Unelma uudelleenkäytettävistä tyylinpätkistä CSS:ssä ei ole suinkaan kuollut. Ongelmat, joita @apply pyrki ratkaisemaan, ovat edelleen hyvin todellisia, ja kehittäjäyhteisö on sittemmin omaksunut useita tehokkaita, tuotantovalmiita vaihtoehtoja. Tässä on, mitä sinun tulisi käyttää tänään.

Vaihtoehto 1: Hallitse CSS Custom Properties (tarkoitettu tapa)

Suorin, natiivi ratkaisu on käyttää CSS Custom Properties -ominaisuutta niiden alkuperäiseen tarkoitukseen: yksittäisten, uudelleenkäytettävien arvojen tallentamiseen. Sen sijaan, että luot mixinin painikkeelle, luot joukon custom-ominaisuuksia, jotka määrittelevät painikkeen teeman. Tämä lähestymistapa on tehokas, suorituskykyinen ja täysin tuettu kaikissa moderneissa selaimissa.

Esimerkki: Komponentin rakentaminen Custom Properties -ominaisuuksilla

            
:root {
  --btn-padding-y: 0.5rem;
  --btn-padding-x: 1rem;
  --btn-font-size: 1rem;
  --btn-border-radius: 0.25rem;
  --btn-transition: color .15s ease-in-out, background-color .15s ease-in-out;
}

.btn {
  /* Rakenteelliset tyylit */
  display: inline-block;
  padding: var(--btn-padding-y) var(--btn-padding-x);
  font-size: var(--btn-font-size);
  border-radius: var(--btn-border-radius);
  transition: var(--btn-transition);
  cursor: pointer;
  text-align: center;
  border: 1px solid transparent;
}

.btn-primary {
  /* Teemoitus custom-ominaisuuksien kautta */
  --btn-bg: #007bff;
  --btn-color: #ffffff;
  --btn-hover-bg: #0056b3;

  background-color: var(--btn-bg);
  color: var(--btn-color);
}

.btn-primary:hover {
  background-color: var(--btn-hover-bg);
}

.btn-secondary {
  --btn-bg: #6c757d;
  --btn-color: #ffffff;
  --btn-hover-bg: #5a6268;

  background-color: var(--btn-bg);
  color: var(--btn-color);
}

.btn-secondary:hover {
  background-color: var(--btn-hover-bg);
}

            

              
                Copy
              
            
          

Tämä lähestymistapa antaa sinulle teemoitettavia, ylläpidettäviä komponentteja natiivilla CSS:llä. Rakenne määritellään .btn-luokassa, ja teemaa (osa, jonka olisit saattanut laittaa @apply-sääntöön) hallitaan custom-ominaisuuksilla, jotka on sidottu muokkaajiin kuten .btn-primary.

Vaihtoehto 2: Utility-First CSS (esim. Tailwind CSS)

Utility-first-kehykset, kuten Tailwind CSS, ovat vieneet tyylien koostamisen konseptin sen loogiseen päätökseen. Sen sijaan, että luotaisiin komponenttiluokkia CSS:ssä, tyylit koostetaan suoraan HTML:ssä käyttämällä pieniä, yksikäyttöisiä apuluokkia.

Mielenkiintoista on, että Tailwind CSS:llä on oma @apply-direktiivinsä. On ratkaisevan tärkeää ymmärtää, että tämä EI ole natiivi CSS @apply. Tailwindin @apply on käännösaikainen ominaisuus, joka toimii sen ekosysteemin sisällä. Se lukee apuluokkasi ja kääntää ne staattiseksi CSS:ksi, välttäen kaikki natiiviehdotuksen ajonaikaiset suorituskykyongelmat.

Esimerkki: Tailwindin @applyn käyttö

            
/* CSS-tiedostossasi, jonka Tailwind käsittelee */
.btn-primary {
  @apply bg-blue-500 text-white font-bold py-2 px-4 rounded hover:bg-blue-700;
}

/* HTML-koodissasi */
<button class="btn-primary">
  Primary Button
</button>

            

              
                Copy
              
            
          

Tässä Tailwindin @apply ottaa listan apuluokkia ja luo uuden komponenttiluokan, .btn-primary. Tämä tarjoaa saman kehittäjäkokemuksen uudelleenkäytettävien tyylijoukkojen luomisesta, mutta tekee sen turvallisesti käännösaikana.

Vaihtoehto 3: CSS-in-JS-kirjastot

Kehittäjille, jotka työskentelevät JavaScript-kehysten, kuten Reactin, Vuen tai Svelten, parissa, CSS-in-JS-kirjastot (esim. Styled Components, Emotion) tarjoavat toisen tehokkaan tavan saavuttaa tyylien koostaminen. Ne käyttävät JavaScriptin omaa koostamismallia tyylien rakentamiseen.

Esimerkki: Mixinit Styled Components -kirjastossa (React)

            
import styled, { css } from 'styled-components';

// Määritellään mixin templaattiliteraalilla
const buttonBaseStyles = css`
  background-color: #007bff;
  color: #ffffff;
  border: 1px solid transparent;
  padding: 0.5rem 1rem;
  border-radius: 0.25rem;
  cursor: pointer;
`;

// Luodaan komponentti ja sovelletaan mixiniä
const PrimaryButton = styled.button`
  ${buttonBaseStyles}

  &:hover {
    background-color: #0056b3;
  }
`;

// Toinen komponentti, joka käyttää samoja perustyylejä
const SubmitButton = styled.input.attrs({ type: 'submit' })`
  ${buttonBaseStyles}
  margin-top: 1rem;
`;

            

              
                Copy
              
            
          

Tämä hyödyntää JavaScriptin täyttä tehoa luodakseen uudelleenkäytettäviä, dynaamisia ja rajattuja tyylejä, ratkaisten DRY-ongelman komponenttipohjaisessa paradigmassa.

Vaihtoehto 4: CSS-esikääntäjät (Sass, Less)

Älkäämme unohtako työkaluja, joista kaikki alkoi. Sass ja Less ovat edelleen uskomattoman tehokkaita ja laajalti käytettyjä. Niiden mixin-toiminnallisuus on kypsä, monipuolinen (ne voivat hyväksyä argumentteja) ja täysin luotettava, koska, kuten Tailwindin @apply, ne toimivat käännösaikana.

Monille projekteille, erityisesti niille, jotka eivät ole rakennettu raskaan JavaScript-kehyksen päälle, esikääntäjä on edelleen yksinkertaisin ja tehokkain tapa hallita monimutkaisia, uudelleenkäytettäviä tyylejä.

Johtopäätös: @apply-kokeilusta opitut asiat

CSS @apply -säännön tarina on kiehtova tapaustutkimus verkkostandardien evoluutiosta. Se edustaa rohkeaa yritystä tuoda rakastettu kehittäjäominaisuus natiivialustalle. Sen lopullinen poisvetäminen ei ollut idean epäonnistuminen, vaan osoitus CSS Working Groupin sitoutumisesta suorituskykyyn, ennustettavuuteen ja kielen pitkän aikavälin terveyteen.

Tärkeimmät opit nykypäivän kehittäjille ovat:

• Ota CSS Custom Properties käyttöön arvoille, ei sääntöjoukoille. Käytä niitä luodaksesi tehokkaita teemoitusjärjestelmiä ja ylläpitääksesi suunnittelun yhtenäisyyttä.
• Valitse oikea työkalu koostamiseen. Ongelma, jonka @apply yritti ratkaista – tyylien koostaminen – hoidetaan parhaiten omistetuilla työkaluilla, jotka toimivat käännösaikana (kuten Tailwind CSS tai Sass) tai komponentin kontekstissa (kuten CSS-in-JS).
• Ymmärrä verkkostandardien taustalla oleva "miksi". Tietäen, miksi @applyn kaltainen ominaisuus hylättiin, saamme syvemmän arvostuksen selainten suunnittelun monimutkaisuudesta ja CSS:n perusperiaatteista, kuten kaskadista.

Vaikka emme ehkä koskaan näe natiivia @apply-sääntöä CSS:ssä, sen henki elää. Halu modulaarisempaan, komponenttivetoiseen ja DRY-periaatteen mukaiseen lähestymistapaan tyylittelyssä on muovannut moderneja työkaluja ja parhaita käytäntöjä, joita käytämme joka päivä. Verkkoympäristö kehittyy jatkuvasti, ja ominaisuudet kuten CSS Nesting, @scope ja Cascade Layers tarjoavat uusia, natiiveja tapoja kirjoittaa järjestelmällisempää ja ylläpidettävämpää CSS:ää. Matka parempaan tyylittelykokemukseen jatkuu, ja @applyn kaltaisista kokeiluista opitut asiat viitoittavat tietä eteenpäin.