Temiz ve performanslı Açısal uygulama için en iyi yöntemler

Birkaç senedir Trade Me, Yeni Zelanda'da geniş çapta bir Açısal uygulama üzerinde çalışıyorum. Geçtiğimiz birkaç yıl boyunca ekibimiz, hem kodlama standartları hem de performans açısından mümkün olan en iyi durumda olması için uygulamamızı geliştirmektedir.

Bu makale, uygulamamızda kullandığımız uygulamaları özetlemektedir ve Angular, Typescript, RxJs ve @ ngrx / store ile ilgilidir. Uygulamanın daha temiz olmasına yardımcı olmak için bazı genel kodlama kılavuzlarından da geçeceğiz.

1) trackBy

Şablonlardaki bir dizi üzerinde dolaşmak için ngFor'u kullanırken, onu her öğe için benzersiz bir tanımlayıcı döndürecek bir trackBy işleviyle kullanın.

Neden?

Bir dizi değiştiğinde, Angular DOM ağacının tamamını yeniden işler. Ancak trackBy kullanıyorsanız, Angular hangi öğenin değiştiğini bilecek ve yalnızca belirli bir öğe için DOM değişiklikleri yapacaktır.

Bununla ilgili ayrıntılı bir açıklama için lütfen Netanel Basal'ın bu makalesine bakın.

Önce

  • {{item}}
  • Sonra

    // şablonda
  • {{item}}
  • // bileşende
    trackByFn (dizin, öğe) {
       item.id döndür; // öğeye karşılık gelen benzersiz kimlik
    }

    2) const vs let

    Değişkenleri bildirirken, değerin atanmaması için const kullanın.

    Neden?

    Let ve const'ı uygun olan yerlerde kullanmak, bildirimlerin amacını daha açık hale getirir. Derleme zamanı hatası vererek bir değerin yanlışlıkla sabit olarak atanması durumunda sorunların belirlenmesinde de yardımcı olacaktır. Ayrıca, kodun okunabilirliğini artırmaya yardımcı olur.

    Önce

    let car = 'gülünç araba';
    let myCar = `$ {arabam}`;
    izin ver yourCar = `Sizin $ {arabanız};
    if (iHaveMoreThanOneCar) {
       myCar = `$ {myCar} s`;
    }
    if (youHaveMoreThanOneCar) {
       yourCar = `$ {youCar} s`;
    }

    Sonra

    // arabanın değeri tayin edilmedi, bu yüzden bir const yapabiliriz
    const araba = 'gülünç araba';
    let myCar = `$ {arabam}`;
    izin ver yourCar = `Sizin $ {arabanız};
    if (iHaveMoreThanOneCar) {
       myCar = `$ {myCar} s`;
    }
    if (youHaveMoreThanOneCar) {
       yourCar = `$ {youCar} s`;
    }

    3) Borulu operatörler

    RxJs operatörlerini kullanırken pipeable operatörleri kullanın.

    Neden?

    Pipetlenebilir operatörler ağaç sarsılabilirdir, yani yalnızca yürütmemiz gereken kod içe aktarılırken dahil edilir.

    Bu, dosyalarda kullanılmayan operatörleri tanımlamayı da kolaylaştırır.

    Not: Bu, Açısal sürüm 5.5+ gerektirir.

    Önce

    'rxjs / add / operator / map' i içe aktarın;
    ithalat 'rxjs / add / operator / take';
    iAmAnObservable
        .map (değer => değer.item)
        sökünüz (1);

    Sonra

    import {map, take} 'rxjs / operators';
    iAmAnObservable
        .boru(
           map (değer => değer.item),
           almak (1)
         );

    4) API saldırılarını izole et

    Tüm API'ler kurşun geçirmez değildir - bazen API'lerdeki hataları telafi etmek için kodda bir mantık eklememiz gerekir. Gerektiği yerde bileşenlere hacklenmek yerine, bir servisteki gibi tek bir yerde izole etmek ve servisi bileşenden kullanmak daha iyidir.

    Neden?

    Bu, ağ talebinin mümkün olduğu yere yakın bir yere, "API'ye daha yakın" kesmeleri korumaya yardımcı olur. Bu şekilde, kodunuzun daha az kısmı, saldırıya uğramamış kodla başa çıkmak demektir. Ayrıca, tüm saldırıların yaşadığı bir yer ve onları bulmak daha kolay. API'lardaki hataları düzeltirken, kod tabanına yayılabilecek hack'leri aramak yerine, onları bir dosyada aramak daha kolaydır.

    Ayrıca TODO'ya benzer API_FIX gibi özel etiketler oluşturabilir ve düzeltmeleri bununla etiketleyebilirsiniz, böylece bulması daha kolaydır.

    5) Şablonda abone ol

    Bileşenlerden gözlemlenebilirlere abone olmaktan kaçının ve bunun yerine şablondan gözlemlenebilirlere abone olun.

    Neden?

    asenkron borular kendilerini otomatik olarak abonelikten çıkarırlar ve abonelikleri manuel olarak yönetme gereksinimini ortadan kaldırarak kodu daha kolay hale getirir. Ayrıca, bileşende bir aboneliği iptal etmeyi kazara unutmayı unutup hafıza kaybına neden olacak riskini de azaltır. Bu risk, abonelikten çıkarılan gözlemcileri tespit etmek için tüysüz bir kural kullanarak da azaltılabilir.

    Bu aynı zamanda bileşenlerin durumsal olmalarını ve verilerin abonelik dışında mutasyona uğradığı hataları ortaya koymalarını önler.

    Önce

    // şablon

    {{textToDisplay}}

    // bileşen
    iAmAnObservable
        .boru(
           map (değer => değer.item),
           takeUntil (this._destroyed $)
         )
        .subscribe (item => this.textToDisplay = item);

    Sonra

    // şablon

    {{textToDisplay $ | zaman uyumsuz}}

    // bileşen
    this.textToDisplay $ = iAmAnObservable
        .boru(
           map (value => value.item)
         );

    6) Abonelikleri temizleme

    Gözlenebilirlere abone olurken, her zaman take, takeUntil vb. Gibi operatörleri kullanarak onlardan aboneliğinizi iptal ettiğinizden emin olun.

    Neden?

    Gözlenebilirler listesinden çıkmamak, bir bileşen yok edildiğinde / kullanıcı başka bir sayfaya geçtikten sonra bile gözlenebilir akış açık bırakıldığı için istenmeyen bellek sızıntılarına yol açacaktır.

    Daha da iyisi, abonelikten çıkmayan gözlemcileri tespit etmek için ipucu kuralı yapın.

    Önce

    iAmAnObservable
        .boru(
           map (value => value.item)
         )
        .subscribe (item => this.textToDisplay = item);

    Sonra

    Değişiklikleri dinlemek istediğinizde takeUntil kullanmak, başka bir gözlenebilir değer verene kadar:

    private _destroyed $ = yeni Konu ();
    Genel ngOnInit (): void {
        iAmAnObservable
        .boru(
           map (value => value.item)
          // Bileşen yok oluncaya kadar iAmAnObservable'ı dinlemek istiyoruz,
           takeUntil (this._destroyed $)
         )
        .subscribe (item => this.textToDisplay = item);
    }
    Genel ngOnDestroy (): void {
        this._destroyed $ .next ();
        this._destroyed $ .complete ();
    }

    Bunun gibi özel bir konunun kullanılması, bileşendeki birçok gözlemcinin abonelikten çıkmasını yönetmek için kullanılan bir kalıptır.

    Sadece gözlemlenebilir tarafından yayımlanan ilk değeri istediğiniz zaman almak için kullanın:

    iAmAnObservable
        .boru(
           map (değer => değer.item),
           alır (1),
           takeUntil (this._destroyed $)
        )
        .subscribe (item => this.textToDisplay = item);

    TakeUntil'in beraberinde kullandığına dikkat edin. Bu, abonelik, bileşen yok edilmeden önce bir değer almadığında ortaya çıkan bellek sızıntılarını önlemek içindir. Burada TakeUntil olmadan abonelik ilk değeri elde edene kadar hala takılıyordu, ancak bileşen zaten tahrip edildiğinden, hiçbir zaman bir değer elde etmeyecek - bu da bellek sızıntısına neden olacak.

    7) Uygun operatörleri kullanın

    Düzleştirici operatörleri gözlenebilirlerinizle kullanırken, durum için uygun operatörü kullanın.

    switchMap: yeni bir emisyon olduğunda önceki emisyonları yoksaymak istediğinizde

    mergeMap: tüm emisyonları aynı anda ele almak istediğinizde

    concatMap: emisyonları, birbiri ardına yayıldıkları şekilde ele almak istediğinizde

    exhaustMap: önceki bir yayını gerçekleştirirken tüm yeni emisyonları iptal etmek istediğinizde

    Bununla ilgili daha ayrıntılı bir açıklama için lütfen Nicholas Jamieson'un bu makalesine bakın.

    Neden?

    Aynı efekti elde etmek için birden fazla başka operatörü birlikte zincirlemek yerine tek bir operatörün kullanılması, kullanıcıya daha az kod gönderilmesine neden olabilir. Yanlış operatörleri kullanmak, farklı operatörler gözlemcileri farklı şekillerde ele aldığından istenmeyen davranışlara yol açabilir.

    8) Tembel yük

    Mümkün olduğunda, açısal uygulamanızdaki modülleri tembel olarak yüklemeye çalışın. Tembel yükleme, yalnızca kullanıldığında bir şey yüklediğinizde, örneğin yalnızca görüldüğü zaman bir bileşeni yüklemek içindir.

    Neden?

    Bu, yüklenecek uygulamanın boyutunu düşürür ve kullanılmayan modülleri yüklemeyerek uygulama önyükleme süresini iyileştirir.

    Önce

    // app.routing.ts
    {path: 'tembel yüklü', bileşen: NotLazyLoadedComponent}

    Sonra

    // app.routing.ts
    {
      yol: 'tembel yük'
      loadChildren: 'lazy-load.module # LazyLoadModule'
    }
    // tembel-load.module.ts
    {NgModule} '@ açısal / çekirdek' den içe aktar;
    {CommonModule} '@ açısal / ortak' ifadesiyle içe aktarın;
    {RouterModule} '@ açısal / yönlendirici' den içe aktar;
    {LazyLoadComponent} './lazy-load.component' öğesinden içe aktarın;
    @NgModule ({
      ithalat: [
        CommonModule,
        RouterModule.forChild ([
             {
                 yol, yörünge: '',
                 bileşen: LazyLoadComponent
             }
        ])
      ],
      bildirimler: [
        LazyLoadComponent
      ]
    })
    ihracat sınıfı LazyModule {}

    9) Abonelikler dahilinde abonelik yapmaktan kaçının

    Bazen bir eylemi gerçekleştirmek için birden fazla gözlemlenebilir değerleri isteyebilirsiniz. Bu durumda, gözlemlenebilir başka bir abonelik bloğunda gözlemlenebilir birine abone olmaktan kaçının. Bunun yerine uygun zincirleme operatörleri kullanın. Zincirleme operatörleri, operatörün önündeki gözlenebilirler üzerinde çalışır. Bazı zincirleme operatörleri: withLatestFrom, combineLatest, vb.

    Önce

    firstObservable $ .pipe (
       almak (1)
    )
    .subscribe (firstValue => {
        secondObservable $ .pipe (
            almak (1)
        )
        .subscribe (secondValue => {
            console.log (`Birleştirilmiş değerler: $ {firstValue} & $ {secondValue}`);
        });
    });

    Sonra

    firstObservable $ .pipe (
        withLatestFrom (secondObservable $),
        ilk()
    )
    .subscribe (([firstValue, secondValue]) => {
        console.log (`Birleştirilmiş değerler: $ {firstValue} & $ {secondValue}`);
    });

    Neden?

    Kod kokusu / okunabilirliği / karmaşıklığı: RxJ'leri tam olarak kullanmamak, geliştiricinin RxJs API yüzey alanına aşina olmadığını gösterir.

    Performans: Gözlenebilirler soğuksa, ilk gözlemlenebilir olana abone olur, tamamlanmasını bekler, sonra ikinci gözlemlenebilirin çalışmasına başlar. Bunlar ağ istekleri olsaydı, senkron / şelale olarak gösterilirdi.

    10) Herhangi birinden kaçının; her şeyi yazın;

    Daima değişkenlerden veya sabitlerden herhangi bir türden başka bir şey bildirmeyin.

    Neden?

    Typcript'te değişkenleri veya sabitleri yazmadan bildirirken, değişkenin / sabitin yazması kendisine atanan değerden düşülecektir. Bu istenmeyen sorunlara neden olacaktır. Klasik bir örnek:

    const x = 1;
    const y = 'a';
    const z = x + y;
    console.log (`z'nin değeri: $ {z}`
    // Çıktı
    Z'nin değeri 1a

    Bu da bir sayı olmasını beklediğiniz zaman istenmeyen sorunlara neden olabilir. Değişkenleri uygun şekilde yazarak bu sorunlardan kaçınılabilir.

    const x: sayı = 1;
    const y: sayı = 'a';
    const z: sayı = x + y;
    // Bu şöyle derleme hatası verecektir:
    '"A"', 'sayı' yazmak için atanamaz.
    const y: sayı

    Bu şekilde, eksik tiplerin neden olduğu hataları önleyebiliriz.

    Uygulamanızda iyi yazımlara sahip olmanın bir başka avantajı, yeniden düzenlemeyi daha kolay ve güvenli hale getirmesidir.

    Bu örneği düşünün:

    Genel ngOnInit (): void {
        izin myFlashObject = {
            adı: 'benim güzel adım',
            yaş: 'Benim serin yaşım',
            loc: 'Harika konumum'
        }
        this.processObject (myFlashObject);
    }
    public processObject (myObject: any): void {
        console.log (`Ad: $ {myObject.name}`);
        console.log (`Yaş: $ {myObject.age}`);
        console.log (`Konum: $ {myObject.loc}`);
    }
    // Çıktı
    Adı: Havalı adım
    Yaş: benim serin yaş
    Yer: Benim güzel yerim

    Diyelim ki, özellik locını myFlashObject içindeki konuma yeniden adlandırmak istiyoruz:

    Genel ngOnInit (): void {
        izin myFlashObject = {
            adı: 'benim güzel adım',
            yaş: 'Benim serin yaşım',
            konum: 'Harika konumum'
        }
        this.processObject (myFlashObject);
    }
    public processObject (myObject: any): void {
        console.log (`Ad: $ {myObject.name}`);
        console.log (`Yaş: $ {myObject.age}`);
        console.log (`Konum: $ {myObject.loc}`);
    }
    // Çıktı
    Adı: Havalı adım
    Yaş: benim serin yaş
    Yer: tanımsız

    MyFlashObject üzerine bir yazı yazmazsak, myFlashObject üzerindeki özellik konumunun geçerli bir özellik olmadığı yerine tanımsız olduğunu düşünüyor.

    MyFlashObject için bir yazı yazmış olsaydık, aşağıda gösterildiği gibi güzel bir derleme zamanı hatası alırdık:

    FlashObject türü = {
        name: string,
        yaş: string,
        konum: dize
    }
    Genel ngOnInit (): void {
        izin myFlashObject: FlashObject = {
            adı: 'benim güzel adım',
            yaş: 'Benim serin yaşım',
            // Derleme Hatası
            '{Name: string; yaş: string; loc: string; } '' FlashObjectType 'yazın.
            Nesne değişmezi yalnızca bilinen özellikleri belirtebilir ve 'loc', 'FlashObjectType' türünde mevcut değil.
            loc: 'Harika konumum'
        }
        this.processObject (myFlashObject);
    }
    public processObject (myObject: FlashObject): void {
        console.log (`Ad: $ {myObject.name}`);
        console.log (`Yaş: $ {myObject.age}`)
        // Derleme Hatası
        'Loc' özelliği 'FlashObjectType' türünde mevcut değil.
        console.log (`Konum: $ {myObject.loc}`);
    }

    Eğer yeni bir projeye başlıyorsanız, katı ayarlamaya değer: tüm katı tip kontrol seçeneklerini etkinleştirmek için tsconfig.json dosyasında true.

    11) Tüy bırakma kurallarından yararlanın

    tslint, kod tabanınızdaki belirli kuralları uygulamak için tslint.json'unuzda yapılandırabileceğiniz hiçbir sihir, sihir numarası, no-konsol vb. gibi çeşitli seçeneklere sahiptir.

    Neden?

    Tüy bırakmayan kurallara uymak, olmamanız gereken bir şeyi yaparken, güzel bir hata yapacağınız anlamına gelir. Bu, uygulamanızdaki tutarlılığı ve okunabilirliği artıracaktır. Yapılandırabileceğiniz daha fazla kural için lütfen buraya bakın.

    Bazı tüy bırakmayan kurallar, tüy bırakma hatasını çözmek için düzeltmelerle birlikte gelir. Kendi özel kural kuralınızı yapılandırmak istiyorsanız, bunu da yapabilirsiniz. Lütfen kendi özel tüy bırakma kurallarınızı TSQuery kullanarak nasıl yazacağınız konusunda Craig Spence tarafından yazılan bu makaleye bakın.

    Önce

    Genel ngOnInit (): void {
        console.log ('Yaramaz bir konsol günlüğü iletisiyim');
        console.warn ('Ben yaramaz bir konsol uyarı mesajıyım');
        console.error ('Ben yaramaz bir konsol hata mesajıyım');
    }
    // Çıktı
    Hata yok, aşağıdakileri konsol penceresinde yazdırır:
    Ben yaramaz bir konsol mesajıyım
    Ben yaramaz bir konsol uyarı mesajıyım
    Ben yaramaz bir konsol hata mesajıyım

    Sonra

    // tslint.json
    {
        "kurallar": {
            .......
            "konsol yok": [
                 doğru,
                 "log", // console.log'a izin verilmez
                 "uyar" // konsolun uyarılmasına izin verilmez
            ]
       }
    }
    // ..component.ts
    Genel ngOnInit (): void {
        console.log ('Yaramaz bir konsol günlüğü iletisiyim');
        console.warn ('Ben yaramaz bir konsol uyarı mesajıyım');
        console.error ('Ben yaramaz bir konsol hata mesajıyım');
    }
    // Çıktı
    Console.log ve console.warn ifadeleri için Lint hataları ve config dosyasında belirtilmediği gibi console.error hatası yok
    'Console.log' çağrısına izin verilmiyor.
    'Konsol'da uyar' çağrısına izin verilmez.

    12) Küçük yeniden kullanılabilir bileşenler

    Bir bileşende tekrar kullanılabilecek parçaları çıkarın ve yenisini yapın. Bileşeni mümkün olduğu kadar dilsiz yapın, çünkü bu daha fazla senaryoda çalışmasını sağlar. Bir bileşeni dilsiz yapmak, bileşenin içinde özel bir mantığa sahip olmadığı ve yalnızca kendisine sağlanan giriş ve çıkışlara dayalı olarak çalıştığı anlamına gelir.

    Genel bir kural olarak, bileşen ağacındaki son çocuk en aptalca olacaktır.

    Neden?

    Yeniden kullanılabilir bileşenler, kodun tekrarlanmasını azaltır, böylece bakımı ve değişiklik yapılmasını kolaylaştırır.

    Dumb bileşenleri daha basittir, bu nedenle böcek olma olasılığı daha düşüktür. Dumb bileşenleri, genel bileşen API'si hakkında daha fazla düşünmenizi sağlar ve karışık endişelerin giderilmesine yardımcı olur.

    13) Bileşenler yalnızca ekran mantığı ile ilgilenmelidir

    Bileşeni yalnızca ekran mantığı ile ilgilenebildiğiniz ve yapabileceği zaman bileşeninizde ekran mantığı dışında herhangi bir mantık kullanmaktan kaçının.

    Neden?

    Bileşenler sunum amaçlı tasarlanmıştır ve görünümün ne yapması gerektiğini kontrol eder. Herhangi bir iş mantığı, uygun olduğunda iş mantığını görüş mantığından ayırarak kendi yöntemlerine / hizmetlerine çıkarılmalıdır.

    İş mantığı genellikle bir hizmete verildiğinde birimin test edilmesi kolaydır ve aynı iş mantığına ihtiyaç duyan herhangi bir bileşen tarafından tekrar kullanılabilir.

    14) Uzun yöntemlerden kaçının

    Uzun yöntemler, genellikle çok fazla şey yaptıklarını göstermektedir. Tek Sorumluluk İlkesini kullanmaya çalışın. Yöntemin bir bütün olarak tek bir şeyi yapıyor olabilir, ancak bunun içinde gerçekleşebilecek birkaç işlem daha var. Bu yöntemleri kendi yöntemlerine ekleyebilir ve her birini bir şey yapmalarını ve yerine kullanmalarını sağlayabiliriz.

    Neden?

    Uzun yöntemleri okumak, anlamak ve sürdürmek zordur. Bir şeyi değiştirmek, bu yöntemde bir çok şeyi etkileyebileceğinden, böceklere de eğilimlidirler. Ayrıca refactoring'i (herhangi bir uygulamada anahtar olan bir şey) zorlaştırır.

    Bu bazen “siklomatik karmaşıklık” olarak ölçülür. Projenizde hataları önlemek ve kod kokularını ve bakım sorunlarını tespit etmek için kullanabileceğiniz döngüsel / bilişsel karmaşıklığı saptamak için bazı TSLint kuralları da vardır.

    15) KURU

    Kendini tekrar etme. Kod tabanında, aynı kodun farklı yerlere kopyalanmadığından emin olun. Tekrarlayan kodu çıkartın ve tekrarlanan kodun yerine kullanın.

    Neden?

    Aynı kodu birden fazla yerde kullanmak, bu koddaki mantığı değiştirmek istiyorsak, birden fazla yerde yapmamız gerektiği anlamına gelir. Bu, bakımını zorlaştırır ve aynı zamanda tüm olaylarda güncellemeyi özleyebileceğimiz hatalara açıktır. Mantıkta değişiklik yapmak daha uzun sürer ve test edilmesi de uzun bir süreçtir.

    Bu durumlarda, tekrar eden kodu çıkartın ve onun yerine kullanın. Bu, değişecek tek bir yer ve test edilecek bir şey anlamına gelir. Kullanıcılara daha az yinelenen kod gönderilmesi, uygulamanın daha hızlı olacağı anlamına gelir.

    16) Önbellek mekanizmaları ekleyin

    API çağrıları yaparken, bazılarından gelen yanıtlar sık ​​sık değişmez. Bu gibi durumlarda, bir önbellekleme mekanizması ekleyebilir ve değeri API'den kaydedebilirsiniz. Aynı API için başka bir istek yapıldığında, önbellekte bunun için bir değer olup olmadığını kontrol edin ve öyleyse kullanın. Aksi takdirde, API çağrısını yapın ve sonucu önbellekleyin.

    Değerler değişse de sık sık değişmezse, en son ne zaman önbelleğe alındığını kontrol edebileceğiniz bir önbellek süresi tanıtabilir ve API'yi arayabilir veya aramayacağınıza karar verebilirsiniz.

    Neden?

    Önbellekleme mekanizmasına sahip olmak, istenmeyen API çağrılarını önlemek anlamına gelir. Yalnızca gerektiğinde API çağrıları yaparak ve çoğaltmayı önleyerek, ağ için beklememiz gerekmediğinden uygulamanın hızı artar. Aynı zamanda, aynı bilgileri tekrar tekrar indirmeyeceğimiz anlamına gelir.

    17) Şablonlarda mantıktan kaçının

    Şablonlarınızda herhangi bir mantık varsa, basit bir & & yan tümcesi olsa bile, onu bileşenine ayıklamak iyidir.

    Neden?

    Şablonda mantığa sahip olmak, birimin test edilmesinin mümkün olmadığı ve bu nedenle şablon kodunu değiştirirken hatalara daha yatkın olduğu anlamına gelir.

    Önce

    // şablon
    

    Durum: Geliştirici

    // bileşen
    Genel ngOnInit (): void {
        this.role = 'geliştirici';
    }

    Sonra

    // şablon
    

    Durum: Geliştirici

    // bileşen
    Genel ngOnInit (): void {
        this.role = 'geliştirici';
        this.showDeveloperStatus = true;
    }

    18) Teller güvenli olmalı

    Yalnızca bir değer kümesine sahip olabilecek bir tür dizesi değişkeniniz varsa, onu bir dize türü olarak bildirmek yerine, olası değerlerin listesini tür olarak bildirebilirsiniz.

    Neden?

    Değişkenin türünü uygun bir şekilde bildirerek, çalışma zamanı yerine derleme zamanı sırasında kodu yazarken hataları önleyebiliriz.

    Önce

    özel myStringValue: string;
    if (itShouldHaveFirstValue) {
       myStringValue = 'İlk';
    } Başka {
       myStringValue = 'İkinci'
    }

    Sonra

    özel myStringValue: 'İlk' | 'İkinci';
    if (itShouldHaveFirstValue) {
       myStringValue = 'İlk';
    } Başka {
       myStringValue = 'Diğer'
    }
    // Bu aşağıdaki hatayı verecektir
    '"Diğer"', '"İlk" | "İkinci"'
    (özellik) AppComponent.myValue: "İlk" | "İkinci"

    Daha büyük resim

    Durum Yönetimi

    Uygulamanızın durumunu korumak için @ ngrx / store komutunu ve mağaza için yan etki modeli olarak @ ngrx / efektleri kullanmayı düşünün. Durum değişiklikleri eylemler tarafından tanımlanır ve değişiklikler, redüktörler adı verilen saf fonksiyonlarla yapılır.

    Neden?

    @ ngrx / store duruma bağlı tüm mantığı tek bir yerde izole eder ve uygulama üzerinde tutarlı kılar. Aynı zamanda mağazadaki bilgiye ulaşırken daha performanslı bir uygulama yapılmasına yol açan notlandırma mekanizmasına sahiptir. @ ngrx / store, Angular'ın değişim tespit stratejisiyle birlikte daha hızlı bir uygulamaya yol açar.

    Değişmez devlet

    @ Ngrx / store kullanırken, durumu değişmez yapmak için ngrx-store-freeze kullanmayı düşünün. ngrx-store-freeze, bir istisna atarak durumun değişmesini önler. Bu, istenmeyen sonuçlara yol açan devletin yanlışlıkla mutasyona uğramasını önler.

    Neden?

    Bileşenlerde mutasyon durumu, uygulamanın yüklü olan sıra bileşenlerine bağlı olarak tutarsız davranmasına neden olur. Redux modelinin zihinsel modelini kırar. Mağaza durumu değişir ve yeniden yayılırsa, değişiklikler geçersiz kılınabilir. Endişelerin ayrılması - bileşenler görünüm katmanıdır, durumun nasıl değiştirileceğini bilmemeliler.

    jest

    Jest, Facebook'un JavaScript için birim test çerçevesidir. Kod tabanı üzerinde yapılan test işlemlerini paralelleştirerek birim testini hızlandırır. İzleme modu ile sadece yapılan değişikliklerle ilgili testler yapılır, bu da test için geri besleme döngüsünü kısaltır. Jest ayrıca testlerin kod kapsamını sağlar ve VS Code ve Webstorm'da desteklenir.

    Projenizde Jest'i ayarlarken Jest için ağır yüklerin çoğunu yapacak bir ön ayar kullanabilirsiniz.

    Karma

    Karma, AngularJS ekibi tarafından geliştirilen bir test koşucusu. Testleri çalıştırmak için gerçek bir tarayıcı / DOM gerektirir. Ayrıca farklı tarayıcılarda da çalışabilir. Jest, testleri yapmak için krom başsız / fantomlara ihtiyaç duymaz ve saf Düğümde çalışır.

    Evrensel

    Uygulamanızı Evrensel bir uygulama haline getirmediyseniz, şimdi yapmanın tam zamanı. Angular Universal, Angular uygulamanızı sunucuda çalıştırmanıza izin verir ve statik önceden oluşturulmuş html sayfaları sunan sunucu tarafı işleme (SSR) yapar. Bu, JS paketlerinin yüklenmesini ve ayrıştırılmasını beklemeden veya Angular'ın açılıştan açılmasını beklemek zorunda kalmadan, ekrandaki içeriği neredeyse anında gösterdiği için uygulamayı süper hızlı yapar.

    Ayrıca Angular Universal statik içerik oluşturur ve web tarayıcılarının uygulamayı indekslemesini ve JavaScript çalıştırmadan aranabilir olmasını kolaylaştırdığından SEO dostudur.

    Neden?

    Universal, uygulamanızın performansını önemli ölçüde artırır. Yakın zamanda sunucu tarafımıza aktarma yapmak için uygulamamızı güncelledik ve site yükleme süresi birkaç saniyeden onlarca milisaniyeye ulaştı !!

    Ayrıca, sitenizin sosyal medya önizleme snippet'lerinde doğru şekilde görünmesini sağlar. İlk anlamlı boya gerçekten çok hızlı ve istenmeyen bir gecikme olmadan içeriği kullanıcılar tarafından görülebilir hale getiriyor.

    Sonuç

    Uygulama oluşturmak sürekli bir yolculuktur ve işleri geliştirmek için her zaman yer vardır. Bu optimizasyon listesi başlamak için iyi bir yer ve bu kalıpları tutarlı bir şekilde uygulamak takımınızı mutlu edecek. Kullanıcılarınız ayrıca daha az adamcağınız ve performans sergileyen uygulamanızla güzel bir deneyim için sizi sevecektir.

    Okuduğunuz için teşekkürler! Bu makaleyi beğendiyseniz, lütfen ve başkalarının onu bulmasına yardımcı olmaktan çekinmeyin. Lütfen düşüncelerinizi aşağıdaki yorum bölümünde paylaşmaktan çekinmeyin. Daha fazla makale için beni Orta veya Twitter'da takip edin. Mutlu kodlama millet! ️