JS’de CSS aslında nedir?

by:

İnternet

JavaScript’teki CSS tartışmalıdır – ve yalnızca React geliştiricileri için değil, bir göz atmaya değer olabilir. CSS-in-JS kitaplığına karar verirken size yardımcı olabilecek konsepti ve soruları formüle ediyoruz.

Temel olarak ilke basittir: Stil sayfaları yerine CSS’nizi bileşenlere yerleştirirsiniz. Neredeyse 50 seçenekle doğru CSS-in-JS kitaplığını seçmek zor olabilir ve sonuçta bu sizin özel kullanım durumunuza bağlıdır. Ancak, tüm kitaplıkların bazı ortak özellikleri vardır:

Kapsamlı CSS ✔️

Tüm CSS-in-JS kitaplıkları, CSS Modülleri ile popüler hale gelen bir fikir olan CSS sınıflarınız için benzersiz adlar oluşturur. Tüm stiller yalnızca ilgili bileşenlerini etkiler. Bileşenin dışındaki stil, onlardan tamamen etkilenmez ve bunun tersi de geçerlidir. CSS sınıflarınızın adlarının çakışması, özgünlükle ilgili sorunlar olması veya on iki bin CSS sınıfının anlamlı bir şekilde adlandırılmasıyla ilgili mücadele geçmişte kaldı. Bileşen tabanlı bir yaklaşıma güvenen geliştiricilerin – örneğin React – CSS-in-JS kitaplıklarına bu kadar değer vermelerinin nedeni de budur:


import React, {Component} from 'react';
import styled from 'styled-components';
const Background = styled.div`
background: red
const Paragraph = styled.p` color: white  `
class App extends Component { render() {
>return (
<Background>
<Paragraph>t3n - digital pioneers</Paragraph>
</Background>
export default App;
`

Örnekte, burada popüler CSS-in-JS kitaplığı StyledComponents for React ve React Native ile stiller aşağı yukarı bileşen tarafından çevrelenir ve yalnızca onu etkiler.

Satır içi stil yok ✔️

HTML içinde atanan stiller, satır içi stiller olarak adlandırılır. Sözde sınıflar, sözde öğeler ve medya sorguları bu gösterimle hariç tutulur. Satır içi stilleri kullanan duyarlı tasarımlar da mümkün değildir. Ayrıca, satır içi stillerin genellikle sınıf adlarından daha az verimli olduğu düşünülür. Yeni CSS-in-JS kitaplıklarının çoğunun, sözde sınıflara ve öğelere, medya sorgularına ve ana kare animasyonlarına izin vermek için satır içi stilleri CSS sınıf adları lehine terk etmesinin iki iyi nedeni.

Otomatik satıcı önekleri ✔️

Karmaşık CSS standardizasyon süreci nedeniyle yeni CSS özelliklerinin tüm tarayıcılarda kullanıma sunulması genellikle yıllar alır. Yeni, henüz standartlaştırılmamış özellikleri önceden kullanılabilir hale getirmek için, standartlaştırılmamış CSS sözdizimi, satıcı öneki adı verilen bir ad altında teslim edilir. Eski tarayıcılarda, yeni özellikler genellikle desteklenmez, bu durumda önekler kullanılır. Hangi özelliklerin hangi tarayıcı için gerekli olduğunu ezbere bilmek, özellikle güncellemelerin ve yeni sürümlerin yayınlanmasıyla zamanla değişebileceğinden, belki biraz abartılı olabilir. caniuse.com gibi kaynaklar burada değerli kaynaklar olabilir.
JS kitaplıklarındaki CSS’lerin çoğu, geliştiricileri bu görevden nazikçe kurtarır. Bu, yalnızca standart sözdizimini kullanabileceğiniz ve kitaplığın satıcı öneki dahil olmak üzere bu özellikleri otomatik olarak oluşturacağı anlamına gelir.

Sunucu tarafı oluşturma ✔️

Tek sayfalı uygulamalar veya SPA’lar genellikle sunucu tarafı oluşturma olmadan çalışır. Geleneksel olarak tarayıcıda oluşturulurlar. Http sunucusundan yalnızca ilk, boş bir HTML sayfası gelir. Arama motorları tarafından ayrıştırılması ve dizine eklenmesi gereken web siteleri ve uygulamalar, çeşitli nedenlerle sunucuda oluşturulan sayfalara sahip olmalıdır. Aynı durum, içeriğin oluşturma süresi boyunca ilişkili CSS ile birlikte statik HTML dosyaları olarak oluşturulduğu statik site oluşturucular için de geçerlidir. Çoğu CSS-in-JS kitaplığı SSR’yi destekler, böylece bunları her türlü web projesi için kullanabilirsiniz.

farklılıklar

Benzerlikler için çok fazla. Ayrıntılı olarak, çeşitli CSS içinde JS kitaplıkları birkaç noktada farklılık gösterir. Styled Components veya Stitches gibi bazıları özellikle React için geliştirildi, diğerleri – JSS, Treat, Emotion – çerçeveden bağımsızdır. Çoğu, HTML, CSS ve JS’nin aynı dosyada olmasına izin veren bir formatı destekler; bu, birçok durumda bir avantajdır. Bu, hangi stilin hangi bileşene ait olduğunu bir bakışta görebileceğiniz anlamına gelir. Stillerin bir dosyayı çok kafa karıştırıcı hale getirmesi durumunda, bunları ayrı bir CSS dosyasında saklama seçeneği her zaman vardır. Kitaplığa bağlı olarak, stiller ya ES şablon değişmezleri içinde bir dize olarak ya da nesne stilleri sözdiziminde normal JS nesneleri olarak tanımlanabilir. Bazı kütüphaneler – Tarz Bileşenler, Derlenmiş,

Bu şekilde tanımlanan stilleri kullanmak için de birkaç seçenek vardır.

class niteliği veya className özellik varyantı

CSS konusunda bilgili geliştiriciler için muhtemelen en kolay yol: stilleri sınıf adları olarak atamak. Bu CSS-in-JS kitaplıkları, daha sonra HTML öğelerine atanabilen API aracılığıyla sınıf adlarını bir dize olarak verir.

// "css" is the API of a generic CSS-in-JS library here
const heading_style = css({
color: "red"
});

const heading = `<h2 class="${heading_style}">Title</h2>`;
function Heading() { return <h2 className={heading_style}>Title</h2>; }

Bu yöntem muhtemelen en çok geleneksel CSS’ye benzer: Önce bir stil tanımlanır ve ardından bu şekilde tasarlanacak öğelere uygulanır. Diğerlerinin yanı sıra Treat, Emotion, Goober, Fela, JSS, Stitches, TypeStyle ve Styled JSX tarafından desteklenmektedir.

<stillenmiş> varyant

Bir başka popüler yürüyüş biçimi, <styled> çeşididir. İlk olarak Styled Components Library’de tanıtıldı. Bu yaklaşım, stilleri ayrı ayrı tanımlamak yerine, öğeyi ve ilişkili stili birlikte tanımlar. Styled Components API daha sonra istenen stile sahip yeni bir bileşen döndürür. Stitches, Emotion, Styled Components ve Compiled tarafından desteklenir.

CSS Özellik Yöntemi

Emotion adlı bir kitaplık tarafından popüler hale getirilen daha yeni bir yaklaşım, özel özelliklere stiller atayarak çalışır. Ancak API yalnızca JSX ile kullanılabilir. Bu yaklaşımın avantajı, bir API’yi içe aktarmaya gerek olmamasıdır; stiller, satır içi stillerin kullanımına benzer şekilde, CSS özelliğine aktarılabilir. .css özelliği standart bir HTML niteliği olmadığı için ilgili kitaplık tarafından sağlanan ayrı bir eklentinin yüklenmesi gerekir.

Stilleri tarayıcıda sunmanın 2 yöntemi

Stillerin tarayıcıda teslim edilmesinin iki yolu vardır.

Çalışma zamanında DOM enjeksiyonu

Çoğu CSS-in-JS kitaplığı, stilleri çalışma zamanında DOM’ye ekler. SSR sırasında HTML sayfasına eklenen <style> etiketlerini veya stilleri doğrudan CSS nesne modeli içinde yönetmek için CSSStyleSheet adlı bir API kullanırsınız. SSR sırasında HTML sayfasına stillerin eklenmesi performans üzerinde olumlu bir etkiye sahiptir çünkü oluşturma işlemini engellemek için sunucudan alınması gereken ayrı bir CSS dosyası yoktur. Bu yaklaşım, kullanıma hazır kritik CSS çıkarımı sunar; Bu, SSR sırasında HTML belgesine yalnızca ilk görünümü oluşturmak için gerekli olan stillerin eklendiği anlamına gelir. Dinamik stiller kaldırılır, başlangıçta indirilmesi gereken kod miktarı daha da azalır ve yükleme süreleri buna göre azalır.

Ancak, bu yaklaşımla, tarayıcıda dinamik stillerin işlenmesi, ek bir çalışma zamanı kitaplığı olmadan mümkün değildir. Satır içi eklenen SSR stilleri de önbelleğe alınmaz ve her istekte tarayıcıya yeniden gönderilmesi gerekir. Rehidrasyon sırasında tarayıcıya tekrar JS şeklinde iletilirler.

CSS dosyalarının statik olarak çıkarılması

Az sayıda CSS-in-JS kitaplığı temelde farklı bir yaklaşım benimser. DOM’a eklenen stiller yerine, kitaplıklar statik .css dosyaları oluşturur. Performans açısından bu, normal CSS dosyalarıyla karşılaştırılabilir: Tarayıcıya gönderilen kod miktarı çok daha küçüktür, burada ek çalışma zamanı kitaplıkları veya yeniden düzenleme gerekli değildir. Statik .css dosyaları varsayılan olarak tarayıcıda önbelleğe alınır. Bir web sayfasını ilk kez ziyaret ettiğinizde önbellek boştur, bu da ilk içerikli boyamanın ilk bahsedilen yönteme göre daha uzun sürdüğü anlamına gelir. Dinamik stiller başlangıçtan itibaren pakete dahil edilmiştir, bu nedenle tarayıcı tarafından yüklenmesi gereken CSS potansiyel olarak daha büyüktür.
Çoğu CSS kitaplığı stilleri DOM’a ekler. Treat, style9 ve Linaria dahil olmak üzere yalnızca birkaçı CSS dosyalarının statik olarak çıkarılmasını destekler.

atomik CSS

Bazı kütüphaneler Atomic CSS ile üçüncü bir yaklaşımı benimser. Tailwind veya Tachyons gibi CSS çerçevelerinden ilham alıyor . Belirli bir öğe için tanımlanmış tüm özellikleri içeren bir CSS sınıfı yerine, bu kitaplıklar her özellik-değer kombinasyonu için bir CSS sınıfı oluşturur ve bu sınıf daha sonra tüm kod tabanında yeniden kullanılabilir.
Teoride, bu yaklaşım, sınıfların sıklıkla yeniden kullanıldığı büyük uygulamalar için özellikle uygundur. Tek sorun: sınıf adlarının HTML öğelerinin her birine uygulanması gerekir, bu nedenle HTML dosyası daha büyük olacaktır. Bununla birlikte, bu yaklaşımla, tarayıcıya teslim edilen bayt miktarı, daha önce bahsedilenlerden ortalama olarak daha küçüktür.

Doğru kitapları bulun

Buraya kadar okuyan herkes, doğru kütüphaneye karar vermenin kolay olmadığını anlayacaktır. Ancak, birkaç soruyu yanıtlamak, hangi kitaplığın sizin için doğru olduğuna karar vermenize yardımcı olabilir:

  • Proje React kullanıyor mu, kullanmıyor mu? Öyleyse, geliştiriciler çok çeşitli CSS-in-JS kitaplıkları arasında seçim yapmakta zorlanırlar. Ancak farklı bir çerçeve veya Vanilla JS kullanan uygulamalar için çerçeveden bağımsız bir kitaplık kullanılmalıdır.
  • Uygulama çok etkileşimli mi ve istemci tarafında işlemeye mi dayanıyor yoksa SSR’li dinamik bir web sitesi mi? Bu durumda, statik CSS dosyalarını çıkarmak muhtemelen daha akıllıca olacaktır. Uygulama önbelleğe alma işleminden bu şekilde yararlanır.
  • Taşınması gereken CSS’nin zaten var olup olmadığı da seçimi etkiler. Bu durumda, etiketli şablonları destekleyen bir CSS-in-JS kitaplığı kullanılması önerilir. Bu, göçü kolaylaştırır.
  • Ayrıca, uygulamanın ilk kez gelen ziyaretçiler veya geri gelen kullanıcılar için optimize edilip edilmeyeceği de bir rol oynar. Statik .css dosyaları, geri dönen kullanıcılar için en iyi UX’i sunar, ancak ilk ziyarette sayfanın oluşturulmasını geçici olarak engelleyen ek bir http isteği gerekir. Ancak, uygulamanıza sık sık yeni bir görünüm kazandırmayı düşünüyorsanız, seçiminizi yaparken elbette önbelleğe alma faktörünü dışarıda bırakabilirsiniz.
  • Geliştiriciler bir uygulamada stilleri ve bileşenleri birden çok kez kullanıyorsa, Atomic CSS’ye dayalı çerçeveler muhtemelen en iyi seçenektir.

Comments are closed.