BEM'i LESS gibi nesnel bir stil sayfası dili kullanmaktan daha iyi yapan şey nedir?

Bir meslektaşım, yürüttüğü bir projede CSS için BEM ( Blok Eleman Değiştirici ) yöntemini çok zorluyor ve yıllardır yazdığımız LESS CSS'den daha iyi kılan şeyin ne olduğunu anlayamıyorum.

"Daha yüksek performans" olduğunu iddia ediyor, ancak bu kod mağazasında yazdığımız web uygulamaları için performansın ne kadar önemli olduğunu hayal bile edemiyorum. Burada Twitter veya Facebook yapmıyoruz. En yüksek kullanımlı uygulamalarımızda ayda 10000'den fazla hit varsa ve çoğu 1000'in altındaysa çok şaşırırdım.

"Okunabilirlik" ve "yeniden kullanım" olduğunu iddia ediyor, ancak LESS bence çok daha iyisini yapıyor . Ve BEM'in bu süper-uzun sınıf isimlerine adanmış düzinelerce fazladan karakterle okunaklılığı azaltan çok kötü bir şekilde yönettiğini hissediyorum .

“İç içe CSS'nin bir anti-kalıp olduğunu” iddia ediyor. "Anti-patern" bile ne anlama geliyor ve iç içe CSS neden kötü?

“Herkes BEM kullanmaya doğru gidiyor, bu yüzden biz de yapmalıyız” diyor. Sayacım "Herkes bir köprüden atlasaydı, izler miydin?" Ama yine de bu konuda tamamen kararlı.

Birisi BEM'i LESS'ten daha iyi yapan şeyleri ayrıntılı olarak açıklayabilir mi? Meslektaşım beni ikna edemedi, ancak takip etmekten başka seçeneğim olup olmadığını bilmiyorum. İsteyerek kabullenmekten çok, BEM'i takdir etmeyi tercih ederim.

Bir meslektaşım, yürüttüğü bir projede CSS için BEM (Blok Eleman Değiştirici) yöntemini çok zorluyor ve yıllardır yazdığımız LESS CSS'den daha iyi kılan şeyin ne olduğunu anlayamıyorum.

BEM bir CSS metodolojisidir. Diğerleri arasında OOCSS ve SMACSS bulunur. Bu metodolojiler, iyi performans gösteren modüler, genişletilebilir, tekrar kullanılabilir kodlar yazmak için kullanılır.

LESS bir CSS önişlemcisidir. Diğerleri Sass ve Stylus'tur. Bu önişlemciler, kendi kaynaklarını, genişletilmiş CSS'ye dönüştürmek için kullanılır.

BEM ve LESS birbirlerinden "daha iyi" oldukları için karşılaştırılamaz, farklı amaçlara hizmet eden araçlardır. Belirli bir sorunu çözmek için bir yardımcı program düşünmek dışında, bir tornavidanın çekiçten daha iyi olduğunu söyleyemezsiniz.

"Daha yüksek performans" iddia ediyor ...

Performansın klasik CSS stili arasında ölçülmesi gerekir:

.widget .header

ve BEM tarzı:

.widget__header

fakat genel olarak konuşursak, CSS seçici performansı bir tıkanıklık değildir ve optimize edilmesi gerekmez.

BEM "performans" genellikle bir geliştiricinin performans yazma kodu ile ilgilidir. BEM metodolojisi tutarlı ve doğru kullanılırsa, geliştirici gruplarının aynı anda stil çarpışmaları olmadan farklı modüller yazması kolaydır.

"Okunabilirlik" ve "yeniden kullanım" iddia ediyor ...

BEM'in daha okunaklı olduğunu yeni bir geliştiriciye söyleyeceğimi bilmiyorum. Sınıfların anlamı ve yapısı hakkında iyi tanımlanmış bazı kılavuzlar sağladığını söyleyebilirim.

Gibi bir sınıf görmek

.foo--bar__baz

Durumda olan ve bir element içeren bir fooblok olduğunu söyler .barbaz

BEM'in klasik bir modelden daha fazla tekrar kullanılabilir olduğunu kesinlikle söyleyebilirim.

İki geliştirici bloklar ( foove bar) oluşturursa ve bu blokların her ikisi de başlıklara sahipse , bloklarını adlandırma çakışması endişesi olmadan farklı bağlamlarda güvenle yeniden kullanabilir.

Bir klasik bir anlamda, en, çünkü .foo .headingve .bar .headingçakışmaması ve muhtemelen bir vaka ile ayrı ayrı, çözülmesi gereken verecek bir özgüllük çatışma getirecek.

Bir BEM sitesinde, sınıflar olacaktır .foo__headingve .bar__headingbunlar asla çatışmaz.

“İç içe CSS'nin bir anti-kalıp olduğunu” iddia ediyor. "Anti-patern" bile ne anlama geliyor ve iç içe CSS neden kötü?

Bir "anti-patern", deneyimsiz geliştiricilerin öğrenmesi ve kullanması için daha uygun bir alternatiften daha kolay bir kodlama paternidir.

Yuvalanmış CSS'nin neden kötü olduğu kadarıyla: Yuvalama, bir seçicinin özgünlüğünü artırır. Spesifiklik ne kadar yüksek olursa, geçersiz kılmak için o kadar fazla çaba harcar. Deneyimsiz geliştiriciler genellikle CSS'lerinin birden fazla sayfayı etkileyebileceğinden endişe ediyorlar, bu nedenle aşağıdaki gibi seçicileri kullanıyorlar:

#something .lorem .ipsum .dolor ul.sit li.amet a.more

Deneyimli bir geliştirici, CSS'lerinin birden fazla sayfayı etkilemeyeceğinden endişe ederse, aşağıdaki gibi seçiciyi kullanırlar:

.more

“Herkes BEM kullanmaya doğru gidiyor, bu yüzden biz de yapmalıyız” diyor.

Bu bir çoğunluk yanlıştır , bu yüzden kötü bir argüman olarak görmezden gel . Yanıltıcı yanılsama tuzağına düşmeyin , çünkü BEM'in desteklenmesinde kötü bir tartışma, BEM'in iyi olamayacağına inanmak için bir neden değildir.

Birisi BEM'i LESS'ten daha iyi yapan şeyleri ayrıntılı olarak açıklayabilir mi?

Bunu daha önce ele aldım, BEM ve LESS karşılaştırılamaz. Elmalar ve portakallar vb.

Meslektaşım beni ikna edemedi, ancak takip etmekten başka seçeneğim olup olmadığını bilmiyorum.

OOCSS, SMACSS ve BEM'e göz atmanızı ve her metodolojinin artılarını ve eksilerini bir ekip olarak tartıyorum . BEM kullanıyorum, çünkü formatın kesinliğini seviyorum ve çirkin seçmenlere aldırış etmiyorum, ama size veya ekibinize neyin doğru olduğunu söyleyemem. Açık sözlü bireyin şovu yönetmesine izin verme. BEM konusunda rahat değilseniz, ekibinizin desteklemesi daha kolay olabilecek başka alternatifler olduğunu unutmayın. Konumunuzu iş arkadaşınızla savunmanız gerekebilir, ancak uzun vadede muhtemelen projelerin sonucunu olumlu yönde etkileyecektir.

İsteyerek kabullenmekten çok, BEM'i takdir etmeyi tercih ederim.

StackOverflow'a BEM'in nasıl çalıştığını açıklayan bir cevap yazdım . Anlaması gereken önemli şey, ideal seçicilerin 0-0-1-0geçersiz kılmak ve genişletmek için kolay olmaları için belirli bir özelliğe sahip olmaları gerektiğidir .

BEM kullanmayı seçmeniz LESS'ten vazgeçmeniz gerektiği anlamına gelmez! Hala değişkenleri kullanabilir, yine de @portport kullanabilirsiniz ve kesinlikle yuvalamayı kullanmaya devam edebilirsiniz. Aradaki fark, oluşturulmuş çıktının soyundan gelen zincirden ziyade tek bir sınıf haline gelmesini istediğinizdir.

Nerede olabilirdi

.widget {
    .heading {
        ...
    }
}

BEM ile kullanabilirsiniz:

.widget {
    &__heading {
        ...
    }
}

Ek olarak, BEM tek tek blokların etrafında döndüğü için kodu kolayca ayrı dosyalara ayırabilirsiniz. widget.lessiçin stilleri içerecektir .widgetederken, bloğun component.lessiçin stiller içerecektir .componentbloğun. Bu, herhangi bir sınıf için kaynak bulmayı çok kolaylaştırır, ancak yine de kaynak haritaları kullanmak isteyebilirsiniz.

2017'yi Düzenle

Bunu 2017'de okuyorsanız, gölge DOM ve gölge DOM polyfills, artı bileşenler tüm bu sorunları çözerek kodunuzu küçük, sıkı ve modüler tutar. Yeşil alan projesi IMO'sunda BEM kullanmayın.

BEM yerine ViewEncapsulation, Polymer, StyledJSX, SASS Modülleri, Styled Components, vs. gibi araçlarımız var.

Bileşen odaklı bir mimariniz yoksa, BEM kullanmayı düşünün; destekleyecek eski kodunuz varsa; veya alet kullanmadan manuel olarak her şeyi yapmaya hazırsanız ölürseniz.

BEM, stilinizi DOM yerleştirmeden bağımsız yapar. Bunu, sayfanızda benzersiz olması muhtemel olan büyük bir eşek sınıfı niteliğini stillendirmek isteyebileceğiniz her öğeye vererek yapar. Çoğu şekillendirme daha sonra derslerde yapılır.

Bu, kodunuzu daha modüler hale getirir, çünkü çok fazla ayrıntıya düşmek pahasına yuvalama artık hesaba katılmaz.

BEM olmadan

BEM olmadan şunu yazabiliriz:

<div class="widget">
  <a>Hello!</a>
  <ul>...</ul>
</div>

Standart CSS stilleri şöyle görünebilir:

.widget {
  border: 1px solid red;
}

.widget a {
  color: green;
}

SASS ile aynı şey şuna benzer:

.widget {
  border: 1px solid red;
  a {
    color: green;
  }
}

Herkesin CSS'yi yüksek bir standarda kodlayabileceği küçük bir takımsanız ve proje tam anlamıyla tam anlamıyla devam edebilecek kadar küçükse, bu iyi ve makul bir çözümdür.

BEM ile

Bununla birlikte, kodunuz daha büyük hale gelirse ve geniş bir karma yetenek ekibiniz varsa, bu o kadar basit bir çözüm olmayabilir. Örneğin yeşil bir çapa başka bir widget'ta isterseniz. Böylece çapayı modüler yapıyoruz ve soyundan gelen seçicileri yok ediyoruz.

Şimdi bizim HTML çok daha ayrıntılı:

<div class="widget">
  <a class="widget__anchor">Hello!</a>
  <ul class="widget__ul">...</ul>
</div>

CSS’nizin soyundan seçenleri yok:

.widget {
  border: 1px solid red;
}

.widget__anchor {
  color: green;
}

Ama şimdi bunu yapabiliriz:

<div class="widget__2">
  <a class="widget__anchor">Hello!</a>
</div>

Widget__anchor modülerdir. Sayfada .widget__anchor'ın başka bir tanımının bulunması muhtemel değildir.

ödünleşimler:

BEM:

• Size daha modüler kod verir. İzole edilmiş herhangi bir parçayı alabilirsin.
• Herkesin CSS yazmasını sağlar. Ana stilin ve özel geçersiz kılmaların farkında olmanıza gerek yok. Büyük bir takımda bu çok hoş.
• Özgüllük sorunlarını giderir.
• Önemli derecede daha ayrıntılı.

Standart CSS (soyundan gelen seçicilerin kullanımına dayanır):

• Stilinizin içeriğe bağlı olduğu anlamına gelir.
• Basamaklı bir farkındalık gerektirir. Bir kerede kod, başka bir yerde kodu etkileyebilir. Küçük bir takımda bu iyi bir şey.
• Acemi bir geliştiricinin hata ayıklaması zor olabilecek özgünlük sorunlarından muzdarip olabilir.
• Önemli ölçüde sıkı.

Üçüncü yol - Gerçek Bileşenler.

Eğer React, Angular 2 veya diğer modern ön uç çerçevelerden herhangi birini kullanıyorsanız, başka bir çözümünüz var. Kapsülleme zorlamak için takım kullanabilirsiniz.

Bu örnekte React ve StyledJSX kullanılıyor, ancak birçok seçenek var. İşte bir widget:

const Widget = () => 
  <div>
    <a>Hello</a>
  </div>
  <style jsx>
    div {border:red }
    a { background: pink }
  </style>

Daha sonra şöyle yeni widget'ı kullanacaksınız:

<Widget />

Pencere öğesinde bildirilen tüm stiller kapsüllenir ve bileşen dışındaki öğelere uygulanmaz. Sayfadaki herhangi bir şeyi yanlışlıkla şekillendirmekten endişe duymadan div, adoğrudan ve doğrudan stil vermekte özgürüz .

Hiçbir yaklaşım mükemmel değildir. IMHO, metodolojilerin her birinin en iyi kısımlarını almalıyız (BEM, SMACSS, OOCSS, DRY). Klasör yapınızı CSS'nizde organize etmek için - özellikle de tüm CSS'nin mantıksal seviyeli dağılımını tanımlamak için SMACSS kullanın. DRY, faydalı kütüphanenizi oluşturmak için ya da bazen BEM tabanlı sınıflarla birlikte kullanılacak ortak değiştirici kitaplığı olabilir. Bileşenler için OOCSS. Ve küçük parçalar veya alt bileşenler için BEM. Orada karmaşıklığı dağıtabilir ve büyük bir ekip içinde çalışma özgürlüğü kazanabilirsiniz.

Özü anlamadan kullanıldığında herhangi bir şey kötü sonuçlanır.

BEM daha büyük takımlar için iyi bir yaklaşım olsa da, bazı olumsuz yönleri de var. 1.Bu bazen büyük HTML yapısında çok uzun isimlerle sonuçlanır. Elde edilen büyük CSS dosya boyutu. 2. 2-3 seviyeden fazla olan htm'lerin iç içe geçmesi için isimleri tanımlamak baş ağrısı olur.

Çok temel bir stil kümesiyle birlikte bileşen yapısını düşünürsek, uyuşmazlık çözümü kolayca yönetilebilir. Sadece iki seviyeli mirastan daha fazlası. Bir bileşenin içindeki her öğenin bir genel stil kuralı vardır veya bu bileşene özgüdür. Bu kolay seçeneklerden biridir.