Yanlışlıkla hataları gizlememeleri için Akış hata bastırmalarını iyileştiriyoruz.

Flow, önümüzdeki yıl, tip sisteminde birçok değişiklik ve iyileştirme yapmayı planlıyor . Bununla birlikte, bunun sonuçlarından biri, Flow mevcut sorunları bulmada daha iyi hale geldikçe kodunuza daha fazla bastırma eklemeniz gerekebilmesidir.

Bu bir sorun olabilir çünkü Flow'un bastırmaları, bastırmayı amaçladığınız orijinal hatadan daha fazlasını etkiler. Bu, Flow'un hataları yakalama yeteneğini azaltır. Bu, iki özelliğin bir sonucudur: Birincisi, Akış bastırmalarının bir tür hatasının herhangi bir bölümüne yerleştirilebilmesi ve ikincisi, Akış bastırmalarının her türlü tür hatasını bastırabileceği . Bu eksiklikleri gidermek için, kodunuzda hatanın fiilen meydana geldiği konuma bastırmaların yerleştirilmesini ve bastırmak istediğiniz hata türünü belirten bir hata kodu içermelerini talep edeceğiz.

Tüm bunların ne anlama geldiğini anlamak için, Flow'un tür hatalarının doğasına bakalım.

Tip hatası nedir?

Flow, kodunuzu kontrol ederken iki tür arasındaki uyumsuzluk veya geçersiz bir özellik erişimi gibi bir sorunla karşılaştığında, kullanıcıya kodunda tam olarak neyin yanlış olduğunu bildiren bir hata oluşturur. Bu hatalar, kendilerine neden olan belirli koşullara bağlı olarak çok çeşitli bilgiler içerebilir, ancak en çok önem verdiğimiz iki hata, hatanın türü ve hatanın konumlarıdır . Tür hata bir işlev ya da bir birlik türünü yayma gibi karmaşık bir şeye çok fazla parametre göndermeden gibi bir şey basit olsun Akış, kodunuzda tespit edilenden kötü davranış belirli yapısı kodlar. Bu bilgi, Flow'a tam olarak nerede yanlış yaptığınızı en iyi şekilde açıklamak için kullanıcıya ne tür bilgilerin gösterileceğini söyler. Konumları hata Hata kodunda bulunduğu hakkında bilgi içerir. Bir hatanın içerebileceği iki tür konum vardır; birincil konum (bunlardan yalnızca biri olabilir) ve çok sayıda olabilen ya da hiç bulunmayan ikincil konumlar. Birincil konum, kodunuzda hatanın fiilen meydana geldiği konuma kabaca karşılık gelirken, ikincil konumlar, hataya dahil olan türlerin ve değerlerin tanım siteleri hakkında bilgi taşır. Örneğin:

function foo(x : number) : void {}
foo("hello");
/* error */
foo("hello");
       ^ Cannot call `foo` with `"hello"` bound to `x` because string [1] is incompatible with number [2].
References:
2: foo("hello");
       ^ [1]
1: function foo(x : number) : void {}
                    ^ [2]

function foo(x : number) : void {}
let y : string = "hello";
foo(y);
/* error */
foo(y);
       ^ Cannot call `foo` with `y` bound to `x` because string [1] is incompatible with number [2].
References:
2: let y : string = "hello";
           ^ [1]
1: function foo(x : number) : void {}
                    ^ [2]

Öyleyse bastırmanın nesi yanlış?

Aslında, bastırmalar hem birincil hem de ikincil konumlara uygulanabileceğinden //$FlowFixMe, tanımının üzerine bir yorum koymak foo, yukarıdaki her iki örnekte de hataları bastıracaktır. Yana fookullanır bunu, o her türlü kullanımı anlamına geleceğini her hata ikincil konum olarak göründüğünü fooo oluşabilir her yerde, bir hataya yol sonuçların bu bir bastırma tarafından bastırılır olacaktır. fooHerhangi bir türden herhangi bir sayıda bağımsız değişkenle çağrı yapabilirsiniz ve Flow, bunlarla ilgili olarak size herhangi bir hata veya uyarı göstermez. Bu, kullanıcıların Flow'un tip kontrolüne olan güvenini azaltır ve aksi takdirde onu üretime sokmak için yakalayacağı hatalara izin verir.

Buna ek olarak, Flow'un bastırmaları, bastırmanın kapsadığı bir konumu içerdikleri sürece her türlü hatayı etkiler. Bu, farklı türdeki çok sayıda hatanın tek bir bastırmayla bastırılabileceği anlamına gelir. Buradaki tehlikeyi görmek için aşağıdaki örneği düşünün:

// library file lib.js
function foo(x : number) : void {}
// impl file
const {foo} = require("lib.js");
let y : string = "hello";
// $FlowFixMe
foo(y);

Bununla ilgili ne yapacağız?

Bu sorunu çözmek için aşağıdaki değişiklikleri yapacağız:

• Birincil konumları zorunlu kılın. Bastırma davranışını, bastırmaların yalnızca birincil konumlarına yerleştirildiğinde hatalara uygulanacağı şekilde değiştireceğiz. Örneğin, işlevin tanımında geçersiz bir çağrıyı bastırmanıza izin vermek yerine, şimdi bastırmanın çağrı sitesinde bulunmasını isteyeceğiz. Bu şekilde Flow, işleve yönelik diğer olası geçersiz çağrılar konusunda sizi yine de uyarabilecektir.
• Hata kodları ekleyin. Ayrıca, yalnızca belirtilen türdeki hataları bastırmaları için bastırmalarımıza hata kodları da ekleyeceğiz. Bu, bastırmaların beklenmedik bir şekilde karşılaşmayı beklemediğiniz bir tür hatayı bastırmasını önleyecektir.
• Bastırma sözdizimini standartlaştırın. Önceden, bir hata bastırma için kabul edilebilir sözdizimi, .flowconfigbelirli bir proje için manuel olarak yapılandırılabiliyordu ve bu da projeler arasında tutarsız bastırma sözdizimine izin veriyordu. Yukarıdaki değişikliklerin bir parçası olarak, bastırma sözdizimini de standartlaştıracağız; yalnızca $FlowFixMe[incompatible-type]veya $FlowExpectedError[incompatible-type]biçimlerini destekler.

Açarak yaymak

Bu değişikliğin, özellikle de kitaplık koduna gizleme yerleştirme alışkanlığınız varsa, kod tabanlarınızda önemli sayıda hatanın geçersiz olmasına neden olabileceğini biliyoruz. Bu yükü hafifletmek için birkaç önerimiz var:

• Yeni geçersiz bastırmalarınızı birincil konumlarına yeniden konumlandırmak için , Akış aracında sağlanan add-commentsve remove-commentsyardımcı programların bir kombinasyonunu öneririz . Çalıştırmak ./tool remove-comments, birincil konumda olmadıkları için artık bir hatayı bastırmayan yorumları kaldıracak ve ./tool add-commentsbastırılmamış konumlara yeni bastırmalar getirecektir. ./toolKomut GitHub'dan Akış deposunu klonlama yoluyla erişilebilir.
• Hata kodu içermeyen bastırmalar, konumlarındaki tüm hataları bastırmaya devam edecektir, ancak hata kodları özelliğini kullanıma sunduğumuzda, yukarıdaki gibi benzer bir işlemle kod tabanınıza uygun kodları ekleyebilirsiniz. Tüm eski yorumlarınızı kaldırıp yeniden eklemek add-comments, yeni eklenen yoruma hata kodunu da ekleyecektir.