Zephyrnet Logosu

Mirage JS Deep Dive: Zamanlamayı, Yanıtı ve Geçişi Anlama (3. Bölüm)

Tarih:

Yazar hakkında

Kelvin Omereshone, CTO'su Quru Laboratuvarı. Kelvin eskiden myPadi.ng'de bir Front-end mühendisiydi. Nuxtjs Africa topluluğunun yaratıcısı ve çok tutkulu ... Hakkında daha fazla bilgi Kelvin ...

Mirage JS Deep Dive serisinin bu üçüncü bölümünde, kullanmaya odaklanacağız. response, timing ve passthrough Gerçek bir arka uç sunucusunun simülasyonunu daha iyi gerçekleştirmek için Mirage'da. Ancak bu makaleyi okumaya başlamadan önce lütfen MirageJS'e giriş ilk olarak Bölüm 1 ve Bölüm 2 bu serinin.

Mirage JS, ön uç geliştiricilere gerçek arka uç API çağrılarını simüle etme yeteneği vermek için oluşturuldu. Şu ana kadar Mirage ile nasıl kayıt oluşturabileceğimizi, rota işleyicileri aracılığıyla API isteklerini nasıl engelleyebileceğimizi ve son fakat bir o kadar da önemli olarak Mirage'dan bize döndürülen verilerin şeklinin nasıl etkilendiğini gördük.

Serinin bu bölümünde, gerçek bir arka uç sunucusunun yavaş ağ, HTTP durum kodu yanıtı gibi diğer yönlerini simüle etmek ve ayrıca Mirage ön uç isteklerinizi engellese bile gerçek bir arka uçtan istekte bulunmak için Mirage mekanizmasını göreceğiz.

Yavaş ağ isteklerini simüle ederek başlayalım.

Zamanlama

Bir arka uç API'sine dayanan ön uç uygulamanızı geliştirirken, uygulamanızın yavaş ağlar altında nasıl davrandığını görmek faydalıdır (mesajları ve yükleyicileri yüklemeyi test etmeyi düşünün). Bu test önemlidir çünkü arka uç API'sine yönelik istekler eşzamanlı olmayan doğada. Bunun anlamı, cevabı ne zaman alacağımıza dair varsayımlarda bulunamayacağımız için kodumuzu sanki hemen gelecekmiş gibi ya da gecikme olabilirmiş gibi yazmamız gerektiği anlamına geliyor.

Yanıttaki gecikmenin yaygın bir nedeni yavaş İnternet bağlantısıdır. Bu durumda uygulamanızın bu gibi durumlarda nasıl davranacağını bilmek gerçekten önemlidir. Mirage, bu ihtiyacı mevcut hale getirerek karşılamaktadır. timing seçenek, bir rota işleyicisine iletilen ve işleyiciye, işlediği rota her çağrıldığında bir yanıt döndürmeden önce zamanlama seçeneği tarafından belirtilen belirli bir süreyi (milisaniye cinsinden) beklemesini söyleyen bir özelliktir.

not: Mirage varsayılan olarak bir 400ms geliştirme sırasında sunucu için gecikme ve 0 testlerinizin daha hızlı çalışabilmesi için test sırasında (kimse yavaş testlerden gerçekten hoşlanmaz).

Artık teoride Mirage'ın sunucu yanıt süresinin nasıl özelleştirileceğini biliyoruz. Bu tepki süresini ayarlamanın birkaç yolunu görelim. timing seçeneği.

timing On rotalar()

Daha önce belirtildiği gibi Mirage, sunucu yanıt süresi için varsayılan bir gecikme ayarlar. 400ms geliştirme sırasında ve 0 testler için. Bu varsayılanı geçersiz kılabilirsiniz. routes Sunucu örneğindeki yöntem.

Aşağıdaki örnekte, ayarlıyorum timing için seçenek 1000ms içinde routes Tüm rotalar için yanıt gecikmesini yapay olarak ayarlama yöntemi:

import { Server } from 'miragejs' new Server({ routes() { this.routes = 1000 }
})

Yukarıdakiler Mirage'a beklemesini söyler 1000 bir yanıt dönmeden önce milisaniye. Dolayısıyla, ön ucunuz aşağıdaki gibi bir rota işleyicisine istekte bulunursa:

this.get('/users', (schema) => { return schema.users.all();
});

Mirage'ın yanıt vermesi 1000 milisaniye sürecektir.

Bahşiş: Doğrudan kullanmak yerine schema rota işleyicinizi aşağıdaki gibi daha temiz ve daha kısa hale getirmek için ES 6 nesne yeniden yapılandırmasını kullanabilirsiniz:

this.get('/users', ({ users }) => { return users.all()
}

timing Bireysel Rotalar İçin

Her ne kadar this.timing özelliği faydalıdır, bazı senaryolarda tüm rotalarınızı geciktirmek istemezsiniz. Bu senaryo nedeniyle Mirage size timing Bir rota işleyicisinin sonuna iletebileceğiniz bir yapılandırma seçenekleri nesnesindeki seçenek. Yukarıdaki kod parçacıklarımızı alarak, 1000ms Küresel olarak ayarlamak yerine rotanın kendisine verilen yanıt gecikmesi:

this.get('/users', ({ users }) => { return users.all(); }, { timing: 1000 });

Sonuç, zamanlamayı genel olarak atamakla aynıdır. Ancak artık bireysel rotalar için farklı zamanlama gecikmeleri belirleme olanağına sahipsiniz. Ayrıca küresel bir zamanlama da ayarlayabilirsiniz. this.timing ve ardından bunu bir rota işleyicisinde geçersiz kılın. Şöyle:

this.timing = 1000 this.get('users', ( { users } ) => { return users.all()
}) this.get('/users/:id', ({ users }, request) => { let { id } = request.params; return users.find(id); }, { timing: 500 });

Şimdi bir istekte bulunduğumuzda /users/1, aşağıdaki kullanıcı JSON'unu diğer tüm rotalar için gereken sürenin yarısında (500ms) döndürecektir.

{ "user": { "name": "Kelvin Omereshone", "age": 23, "id": "1" }
}

Şifreli

Rota işleyicileri, ön uç uygulamanızın yaptığı istekleri engellemek için kullanılan Mirage mekanizmasıdır. Varsayılan olarak Mirage, uygulamanız sunucu örneğinizde bir Rota işleyicisi tanımlamadığınız bir uç noktaya istekte bulunduğunda aşağıdakine benzer bir hata atar.

Hata: Mirage: Uygulamanız şunu denedi: GET '/unknown', ancak bu isteği işlemek için tanımlanmış bir yol yoktu. Bu uç nokta için rotanızı tanımlayın routes() yapılandırma Bir ad alanı tanımlamayı mı unuttunuz?

Ancak Mirage'a, rota işleyicisini tanımlamadığınız bir rotaya yönelik bir istek görürse bu isteğin geçmesine izin vermesi gerektiğini söyleyebilirsiniz. Gerçek bir arka ucunuz varsa ve henüz arka ucunuzda uygulanmamış uç noktaları test etmek için Mirage'ı kullanmak istiyorsanız bu kullanışlıdır. Bunu yapmak için, numarayı aramanız gerekir. passthrough içindeki yöntem routes Mirage sunucu örneğinizdeki yöntemler.

Bunu kod halinde görelim:

import { Server } from 'miragejs' new Server({ routes() { // you can define your route handlers above the passthrough call this.passthrough() }
})

not: Aramayı şu adreste tutmanız önerilir: passthrough Rota işleyicilerinize öncelik vermek için altta.

Artık Mirage, Mirage'da tanımlamadığınız bir rotaya yönelik istekleri gördüğünde, bunların "geçişine" izin verecektir. Bunu gerçekten faydalı buluyorum çünkü Mirage'ın gerçek bir arka uçla güzel bir şekilde oynamasını sağlıyor. Yani bir senaryo şöyle olabilir: Arka uç ekibinizin önündesiniz ve üretim arka ucunuzda olmayan bir uç noktaya istekte bulunmak istiyorsunuz, bu uç noktayı serapta taklit edebilirsiniz ve passthrough seçeneğini kullanarak uygulamanızın diğer bölümlerinin isteklerin başarısız olması konusunda endişelenmenize gerek kalmaz.

kullanma passthrough Rotayı Beyaz Listeye Alma

passthrough Beyaz listeye eklemek istediğiniz rotalar üzerinde daha fazla kontrole sahip olmanızı sağlayacak seçenekleri sunar. Yani aramanın aksine passthrough herhangi bir seçenek olmadan ve serapta mevcut olmayan rotalara izin vererek passthroughbeyaz listeye eklemek istediğiniz rotaların bir veya daha fazla dizesini iletebilirsiniz passthrough. Beyaz listeye almak istiyorsak /reviews ve /pets bunu kullanarak yapabiliriz passthrough öyle:

this.passthrough('/reviews', '/pets)

Ayrıca birden fazla arama da yapabilirsiniz. passthrough:

this.passthrough('/reviews')
this.passthrough('/pets')

not: Birden fazla rota dizesini iletmeyi buluyorum passthrough birden fazla arama yapmak yerine daha temiz. Ancak size doğal gelen her şeyi kullanmakta özgürsünüz.

kullanma passthrough Bir HTTP Fiil Kümesi Üzerine

Yukarıdaki passthrough tanımladığımız tüm HTTP fiillerinin (GET, POST, PATCH, DELETE) passthrough. Kullanım durumunuz HTTP fiillerinin bir alt kümesinin kullanılmasına izin vermenizi gerektiriyorsa passthroughMirage, bir seçenekler dizisi sağlar passthrough Mirage'ın belirli bir rotada beyaz listeye almasını istediğiniz fiilleri ilettiğiniz yöntem. Bunu kod halinde görelim:

// this allows post requests to the /reviews route to passthrough
this.passthrough('/reviews', ['post']);

Ayrıca birden fazla rota dizesinin yanı sıra HTTP fiilleri dizisini de şu şekilde iletebilirsiniz:

// this allows post and patch requests to /reviews and /pets routes to passthrough this.passthrough('/pets', 'reviews', ['post', 'patch'])

yanıt

Artık Mirage'ın size sunduğu özelleştirme düzeyini görüyorsunuz. timing seçenek ve passthrough yöntemine göre, Mirage'ın yaptığınız istekler için gönderdiği HTTP durum kodunu nasıl özelleştireceğinizi bilmeniz size çok doğal geliyor. Varsayılan olarak Mirage şu durumu döndürür: 200 bu da her şeyin yolunda gittiğini söylüyor. (Çıkış yapmak Bu makale HTTP durum kodunu tazelemek için.) Ancak Mirage şunları sağlar: Response HTTP durum kodunu ve ön uç uygulamanıza geri gönderilecek diğer HTTP başlıklarını özelleştirmek için kullanabileceğiniz sınıf.

The Response class size rota işleyiciniz üzerinde daha fazla kontrol sağlar. Aşağıdakileri Response sınıfına iletebilirsiniz inşaatçı:

Nasıl olduğunu görmek için Response sınıf çalışmalarında, önceki rota işleyicimizi kullanarak yeniden yazarak kolay bir notla başlarız. Response sınıf. Yani aşağıdaki rota işleyicisini kullanacağız:

this.get('users', ( { users } ) => {
return users.all()
})

ve ardından şunu kullanarak yeniden uygulayın: Response sınıf. Bunu yapmak için öncelikle içe aktarmamız gerekir. Response Mirage'dan sınıf:

import { Response } from 'miragejs'

Daha sonra rota işleyicimizi şunu kullanarak yeniden yazardık: Response sınıf:

this.get('/users', ({ users }) => { return new Response(200, {}, users.all());
});

not: Boş geçiyoruz {} çünkü bu yanıt için herhangi bir başlık değeri ayarlamak istemiyoruz.

Sanırım kaputun altındaki Mirage'ın Response daha önce döndüğümüzde sınıf users.all() çünkü her iki uygulama da aynı şekilde hareket edecek ve aynı JSON yükünü döndürecektir.

Yukarıdaki kullanımı kabul edeceğim Response Biraz ayrıntılı çünkü henüz özel bir şey yapmıyoruz. Ancak Response class, farklı sunucu durumlarını simüle etmenize ve başlıkları ayarlamanıza olanak tanıyan bir dünya olasılığa sahiptir.

Sunucu Durumlarını Ayarlama

İle Response sınıfını kullanarak artık farklı sunucu durumlarını ilk argüman olan durum kodu aracılığıyla simüle edebilirsiniz. Response yapıcı alır. Artık kötü bir isteği simüle etmek için 400'ü, Mirage'da yeni bir kaynak oluşturduğunuzda oluşturulan durumu simüle etmek için 201'i vb. iletebilirsiniz. Bunu aklımızda tutarak özelleştirelim /users/:id belirli kimliğe sahip bir kullanıcının bulunamadığını simüle etmek için rota işleyicisini ve 404'ü iletin.

this.get('/users/:id', (schema, request) => { let { id } = request.params; return new Response(404, {}, { error: 'User with id ${id} not found'});
});

Mirage daha sonra aşağıdaki JSON yüküne benzer bir hata mesajı içeren bir 404 durum kodu döndürecektir:

{ "error": "User with id 5 not found"
}

İle Response sınıfında, ikinci argüman olarak bir nesneyi ileterek yanıt başlıklarını ayarlayabilirsiniz. Response yapıcı. Bu esneklikle istediğiniz başlığı ayarlamayı simüle edebilirsiniz. Hala bizim aracımızı kullanıyoruz /users/:id rota, başlıkları şu şekilde ayarlayabiliriz:

this.get('/users/:id', (schema, request) => { let { id } = request.params; return new Response(404, {"Content-Type" : "application/json", author: 'Kelvin Omereshone' }, { error: `User with id ${id} not found`});
});

Artık tarayıcı konsolunuzda Mirage günlüklerini kontrol ettiğinizde belirlediğimiz başlıkları göreceksiniz.

Yukarı tamamlayan

Mirage JS Deep Dive serisinin bu bölümünde, Mirage'ın gerçek bir sunucuyu simüle etmek için kullanıcılarına sunduğu üç mekanizmayı anlattım. Bu makalenin yardımıyla Mirage'ı daha iyi kullandığınızı görmek için sabırsızlanıyorum.

Gelecek hafta gelecek olan serinin bir sonraki ve son bölümü için bizi takip etmeye devam edin!

  • Bölüm 1: Mirage JS Modellerini ve İlişkilerini Anlamak
  • Bölüm 2: Fabrikaları, Demirbaşları ve Serileştiricileri Anlamak
  • Bölüm 3: Zamanlamayı, Yanıtı ve Geçişi Anlamak
Smashing Editöryel(Demiryolu)

Kaynak: https://www.smashingmagazine.com/2020/06/mirage-javascript-timing-response-passthrough/

spot_img

En Son İstihbarat

spot_img

Bizimle sohbet

Merhaba! Size nasıl yardım edebilirim?