g u t x .com.tr İpek yolu - Çin'i anlamaya götürürüm

Kişisel küçük ve orta ölçekli projelerin ön uç mimarisinde

1. Neden iyi bir yapı olmalı

Her şeyden önce açık olun, Mimari İhtiyaçlara hizmet eder. Front-end mimarisinin amacı, anladığım kadarıyla şudur:

1. Kod okunabilirliğini artırın

İyi bir mimari için kodun okunabilirliğinin çok güçlü olması gerekir.

Basitçe söylemek gerekirse, eğer ekibe yeni gelen biri katılırsa, projeyi devraldığında başlaması kolay olmalıdır Tüm ön kısım arasındaki ilişkiyi kolayca anlayabilir ve odaklanması gereken noktaları bulabilir. Bu projenin birçok detayına aşina olmak için çok zaman harcamak yerine, bir şeyler yapmaya başlayabilirsiniz.

Dosyalar açısından, dosya adlarından hangilerinin mantık, stiller, yeniden kullanılabilir bileşenler, simge grupları ve mobil veya PC'ye özel dosya adlarından ayırt edebilirsiniz. Stil / mantık vb.

Kod söz konusu olduğunda, birleşik bir adlandırma stili içerir ve aynı dosyada kapsüllenen kodun alaka düzeyi yeterince güçlüdür.

2. Kod sürdürülebilirliğini geliştirin

İyi bir mimarinin bakımı kolay olmalıdır. Örneğin, yeni gereksinimler eklemek, gereksinimleri değiştirmek ve hataları düzeltmek beklenmedik değişikliklere neden olmaz. Örneğin, bir sayfa bileşeninin içeriği değiştirilirse, başka bir sayfa bileşeni oluşur. Değiştir (bu çok kötü). Bu nedenle, düşük bağlantı, yüksek uyum ve girdi ve çıktı tahmin edilebilir.

3. Kod ölçeklenebilirliğini geliştirin

İyi bir mimari, güçlü bir ölçeklenebilirliğe sahip olmalıdır ve sabit kodlanamaz.

Gereksinim değişikliği çok TM normaldir ve yeni gereksinim çok TM normaldir. Bu nedenle, iyi bir mimari bu durumların oluşumunu hesaba katmalıdır çünkü bunlar kesinlikle olacaktır. Bu nedenle, sabit kodlu kodlardan kaçınmalıyız.

Örneğin, sayfa bileşeni A'nın bir takvim bileşenine sahip olması gerekir ve bu takvim bileşeni başka birininkine (örneğin, github'da bulunan) başvurur. Ardından, bu takvim bileşenine doğrudan sayfa bileşeni A'da doğrudan başvurmamaya çalışın, ancak bir takvim bileşeni B yazın, bu takvim bileşeni B'de başvurduğunuz takvim bileşenini kapsülleyin ve ardından çalıştırmak için bu takvim bileşenini B kullanın.

Nedeni basit: Bir gün ürün müdürü bu takvim bileşeninin çok çirkin olduğunu söylüyorsa değiştirelim. Referans verilen takvim bileşeni C'yi doğrudan sayfa bileşeni A'ya yerleştirirseniz, büyük olasılıkla çok sayıda kodu değiştirmeniz gerekecektir (çünkü farklı takvim bileşenlerinin kullanım yöntemi ve görünen arabirimi farklı olabilir). Bu takvim bileşenine başka birçok yerde başvurduysanız, daha da kötüsü! Her yer değiştirilmeli.

Ve referans alınan takvim bileşeni C'yi kendi yazdığınız takvim bileşeni B'ye eklerseniz, yalnızca takvim bileşeni B'deki karşılık gelen kodu değiştirmeniz gerekir ve takvim bileşeni B tarafından gösterilen arabirim değişmediği için doğal olarak gereksizdir. Sayfadaki kodu değiştirin.

Takvim bileşenini örnek alarak ekli resim, ölçeklenebilirliğin sonucu dikkate alındı mı?

Genişletilebilirlik dikkate alınmaz:

Ölçeklenebilirliği göz önünde bulundurarak:

4. İşbirliğini kolaylaştırın

Ön uç ve arka uç arasındaki iş birliği, ön uç ile ön uç arasındaki işbirliği dahil.

Özellikle, ön uç ve arka uç işbirliği genellikle etkileşim olarak ajax kullanır, bu nedenle tüm ajax isteklerini özel olarak kapsayan en az bir dosya olmalıdır ve tüm ajax istekleri burada kapsüllenmiştir. Geliştirme sırasında, burada özetlenen yöntem, ortak hata ayıklamanın geliştirilmesini kolaylaştırarak, üzerinde anlaşmaya varılan etkileşimli içeriği gönderip almayı simüle edebilmelidir.

Ön uç ve ön uç arasındaki işbirliği, esas olarak, diğer tarafın kodunun normal çalışmasını etkilemeden aynı anda kodun değiştirilmesiyle yansıtılır. Bu nedenle paketleme, ayırma ve düşük parazit gereklidir.

5. Otomasyon

Otomatik paketleme, sıkıştırma, gizleme, artı gerekirse otomatik birim testi.

sonuç olarak: Özetle, iyi bir mimarinin amacı, ön uç kod yazmayı rahat hale getirmek, arka uç birleşik hata ayıklamayı rahat hale getirmek ve ürün yöneticisinin gereksinimleri değiştirmesini rahatlatmaktır.

2. Mimariyi nasıl tasarlarım

Mimarimin iyi bir mimari olduğunu söylemeye cesaret edemem (tabii ki hayır) Sadece son zamanlarda yaptığım bir projeyi ve mimarisinin nasıl yapıldığını paylaşabilirim.

İlk önce gereksinimleri belirleyin:

1. Hem mobil hem de PC terminallerine bakan küçük ve orta ölçekli bir web sitesi (tek bir uçta yaklaşık 15 sayfa ve yaklaşık 20 açılır pencere dahil);

2. Bütçe sınırlıdır (daha az para verilir) ve geliştirme süresi sınırlıdır (bir ay);

3. Belirli derecede talep değişiklikleri olabilir (örneğin, sayfa ekleme veya bazı sayfa içeriğini değiştirme);

4. Müşteriler optimizasyonu önemsemeyebilir (ama ben bunu önemsiyorum);

5. IE9 veya üstü ile uyumludur.

Sonra karar vermeye başlayın:

1. IE9 ve üstü ile uyumludur, jQuery'yi kullanmak zorunda kalmadan genel çerçeveler kullanabilirsiniz. Bu yüzden vue kullandım, sürüm 2.0;

2. Bütçe sınırlıdır ve zaman sınırlıdır, bu nedenle PC terminali ve mobil terminal html ve js, bağımsız css paylaşır;

3. Sayfalar sınırlıdır, bu nedenle mimari hiyerarşiyi daha ince bir şekilde bölmeye gerek yoktur, sadece türüne göre bölün;

4. Prototip diyagramına göre, sayfanın karmaşıklığı sınırlıdır ve yeniden kullanım bölümü çok fazla değildir, bu nedenle hangi şeylerin paketlenmesi ve yeniden kullanılması gerektiğini, hangilerinin daha karmaşık olduğunu ve bağımsız olarak paketlenmesi gerektiğini ve hangilerinin daha basit olduğunu ve geliştirme zorluğunu basitleştirmek için doğrudan birleştirilebileceğini belirleyebilirsiniz;

5. Tek sayfalık web sitelerinde daha ustayım, bu nedenle esas olarak tek sayfa biçimini benimsiyorum ve diğer sayfaları eşzamansız olarak yüklüyorum.

Bu nedenle, web paketi, vue-yönlendirici vb. Gibi ilgili destekleyici şeyleri kullanın. Ek olarak, geliştirme ve üretim kolaylığı için geliştirme için aşağıdaki modu kullanın.

Üçüncüsü, işlevi bölün:

Öncelikle, bir kök html var, kullanıcıların js mantığımızı yüklemek için ona erişmeleri gerekiyor, böylece js mantık kodu main.js'de yazılıyor.

Main.js altında, ön uç kodumuz üç bölüme ayrılabilir:

Bileşen ağacı
fonksiyonel modül
Çeşitli kaynaklar

Aşağıda gösterildiği gibi:

İşlevler bölündükten sonra, aynı işlevler aynı klasöre yerleştirilir ve adlandırma stili benzer olmalıdır.

Özellikle, bileşen ağacıyla ilgili şeyler genellikle .vue ile biter ve bileşenler klasörüne yerleştirilir; resimler veya uluslararası kaynaklar dahil olmak üzere kaynaklar .png veya .js veya .json ile biter ve kaynaklar klasörüne yerleştirilir. Aşağı; ve işlevsel eklentiler, hizmetler vb., Birden çok yerde referans verilebildiğinden, başvuru kolaylığı için src klasörünün altına yerleştirilir ve bu klasör, bileşenler klasörünün ve kaynaklar klasörünün üst klasörüdür.

Dördüncü olarak, işlevsel modülleri iyileştirin:

Fonksiyonlar, bileşen ağaçları ve kaynaklar, orada ne olduğunu zaten açıklığa kavuşturduk, bu yüzden sonra, bu şeylerin dosyalar şeklinde nasıl bölünmesi gerektiğini açıklığa kavuşturmalıyız.

Aşağıda gösterildiği gibi:

1. Proje inşaatı ile ilgili

Vue.js kullanmak istediğiniz için, es6 sözdizimini de kullanmanız gerekir. Babil Gereklidir;
Otomatik gizleme ve paketleme nedeniyle web paketi Ayrıca gereklidir;
Son olarak, birden çok kişinin ortak çalışması için uygun olduğu için npmnin package.json Yapılandırma, farklı kişilerin npm kurulumu aracılığıyla hızlı ve otomatik olarak bağımlılıkları kurması için gereklidir.

2. CDN ile ilgili

Ve harici yazı tiplerini kullanmak istediğimiz için (alışılmadık yazı tiplerini tanıtmak için gereklidir), CDN hızlandırma Referansı yapılandırmak için yazı tipi dosyası html'ye yerleştirilmelidir.

3. Yapılandırma ve eklentiler

Bazı eklentileri ve yapılandırma dosyalarını doğrudan tanıtmamız gerekiyor;
Vue kullanmak için bir kök bileşenine ihtiyacımız var, sonra App.vue
Vue-yönlendiriciyi kullanmak için yönlendirme dosyasını yapılandırmamız gerekir. yönlendirici-config.js Bu yönlendirme yapılandırması da gereklidir;
Daha sonra eklentiler biçiminde bazı işlevler ve hizmetler sunmamız gerekir. Eklentinin başında birkaç vue eklentisi- , İhtiyaca göre paketlenmiş düşük birleştirme ve yüksek kohezyon yöntemleridir;

4. Gerekli npm bağımlılıkları

Tabii ki, vue kullanmak istiyorsanız, vue.js'yi tanıtmalısınız, benzer şekilde vue-router.js ve çeşitli uyumluluk çoklu dolgular ve global eklentiler vardır.

5. Çıkarılan işlevsel modüller

Doğrudan referans verilen eklentilere ek olarak, proje ile yüksek oranda bağlantılı bazı işlevsel hizmetlerimiz de var, bunların eklenti olarak kullanılabileceğini düşünmüyorum, ancak yine de kolay kullanım ve değişiklik için çıkarılmaları ve paketlenmeleri gerekiyor;
Örneğin, ajax isteklerini kapsülleyen ajax.js, tüm ajax istekleri içine yerleştirilir, yalnızca arayüz dışarıya açılır, bu da yönetim ve kullanım için uygundur;
Başka bir örnek, uluslararasılaştırılmış kaynakları tanıtması ve uluslararasılaştırılmış kaynakların yüklenmesini yönetmesi gereken gerçek zamanlı uluslararasılaştırma işlevinin bir bileşeni olan LanguageManager.js;
Diğer bir örnek, bileşenler arası iletişimi uygulayan event-bus.js'dir;
Diğer bir örnek, kullanıcı bilgilerini yöneten user.js'dir.

sonuç olarak: Bu ayrımların tümü yukarıdaki resimde yansıtılmıştır. Bu, src dizinindeki işlev modülü dosyasıdır.İhtiyacımız olan işlevlerin çoğu eklenebilir.Bu dosyalarda yalnızca ilgili işlevleri yazmamız ve gerçek geliştirme ihtiyaçlarına göre bunlara referans vermemiz gerekir. Beşincisi, bileşen ağacı:

Fonksiyonel modüllerin bölünmesinden bahsetmeden önce, sonraki bölüm bileşen ağacıdır.

Küçük ve orta boyutlu bir sayfa olduğu için, bileşen ağacının seviyesinin çok derin olması gerekmez, ancak çıkarılması gerekenlerin yine de çıkarılması gerekir. Çıkarılan bileşenlerin ayrıştırıldığından ve bir sayfa bileşeninin mantığının çok fazla olmadığından emin olun. Aşağıda gösterildiği gibi:

0. Kök bileşen

Tüm bileşenler sonunda ortak kök bileşen olan App.vue'yi bulacaktır ve kök bileşen yalnızca doğrudan alt bileşenlerini yönetmekten sorumludur.

Her bileşen, yalnızca kendi doğrudan alt bileşenlerini yönetmekten sorumludur, çapraz düzey yönetimi değil ve kendi alt bileşenlerine bağlı değildir (aksi takdirde, alt bileşenlerin yüklenmemesi veya hatalar nedeniyle ana bileşen hatalarına neden olabilir), ayırma ve dahili Poli.

1. Açılır iletişim kutusu ve açılır ipuçları

Açılır iletişim kutusu ve açılır ipuçları aynı anda var olabileceğinden, kolay yönetim için iki bileşene ayrılmıştır.

2. Giriş yapılmamış sayfa ve giriş sayfası

Sayfa oturum açmış ve oturum açmamış durumda olduğundan ve yükleme hızı göz önüne alındığında, oturum açmadığında oturum açılmış sayfa yüklenmez, bu nedenle eşzamansız olarak bölünmesi ve işlenmesi gerekir.

3. Oturum açılmamış sayfa

Tıklanmamış sayfa üç duruma ayrılmıştır:

İlk sayfa: şüphesiz doğrudan yüklemek
Giriş açılır penceresi: girişe tıkladığınızda yüklenir (eşzamansız)
Kayıt açılır penceresi: kayıt tıklandığında yükle (asenkron)

Bölünmenin nedeni, oturum açmış kullanıcının gereksinimlere göre sayfayı yenilemesi ve doğrudan oturum açma sonrası sayfaya girebilmesidir, bu nedenle oturum açıp kaydolmaya gerek yoktur.Bu işlem trafik tüketimini azaltabilir ve yükleme sayfasının yükleme hızını artırabilir (özellikle kayıt açılır penceresi gereklidir) Hala daha fazla yüklü içerik var).

4. Giriş sayfası

Giriş sayfasında birçok sayfa vardır, ilk sayfa varsayılan olarak yüklenir ve ardından diğer sayfalar eşzamansız olarak (ziyaret edildiğinde) yüklenir.

5. Açılır iletişim kutusu

Mantık az olduğu ve kod miktarı fazla olmadığı için yönetim kolaylığı açısından bir vue dosyası olarak birleştirilir ve aynı açılış mantığı paylaşılır ve geçen anahtara göre hangisi açılır. Bu sayede açılır pencere eklerken açılır pencerenin açılış ve kapanış mantığını yazmaya gerek kalmaz.

Daha karmaşık açılır pencereler varsa, bunlar alt bileşenler biçiminde mevcut vue dosyasına aktarılabilir ve bu da yönetim için uygundur;

6. Uluslararası Yönetim

İlgili uluslararasılaştırılmış kaynakların yüklenmesinden ve yönetimin değiştirilmesinden sorumlu, sayfa ile yüksek oranda birleştirilmiştir.

7. Sayfa Bileşenleri

Normal şekilde alıntılanabilecek alt sayfalar ve yeniden kullanılan bileşenler olabilir.

8. Stil dosyası

Bir .css dosyası olarak bağımsız olarak yazılabilir, ancak daha az genel stil dosyam olduğu için, onu yine de bir .vue dosyasına koyuyorum ve onu App.vue'da referans olarak alıyorum.

9. Sayfa bileşenlerini adlandırma

Genellikle .vue ile biter, ancak uluslararasılaştırılmış LanguageManager.js yüksek oranda bağlanmıştır, bu nedenle .js ile biter ve ayrı bir vue örneğidir, yani vue'nun bir sayfa bileşeninden çok işlevsel bir modül gibi olduğu anlamına gelir;
Oturum açma ve oturum açma olmayan sayfalar, genel bileşenler (ve üstbilgi ve altbilgi) gibi temel sayfalar temel ile başlar;
Açılır pencereler kutu ile başlar;
Yeniden kullanılabilir bileşenler uzatma ile başlar;
İçe aktarılan harici bileşenler ithalatla başlar;
Ortak sayfa bileşenleri page- ile başlar (bu sayfalar genellikle ayrı bir sayfadır ve oturum açma veya oturum açma olmayan sayfaya eklenir);
Kayıt açılır penceresi mantık açısından daha karmaşıktır ve birçok benzer türü vardır, bu nedenle register- ile başlar.