yoklateknik mülakat
GelişimGeçmiş

Frontend State Management Mülakat Soruları

75 doğrulanmış Frontend State Management mülakat sorusu — cevaplarıyla çöz, açıklamalarıyla öğren, gerçek simülasyonda kendini test et.

Gerçek simülasyonu dene →

Örnek sorular

State ManagementZorluk 1
Bir UI component'inde "state" nedir?
  • aBir kez sabit yazılan ve uygulama çalışırken asla değişemeyen konfigürasyon değerleri
  • bBir component'in zaman içinde tuttuğu, değişebilen ve UI'ın ne göstereceğini belirleyen veri✓
  • cTarayıcının herhangi bir script çalışmadan önce parse ettiği statik HTML yapısı
  • dComponent'in ekranda nasıl göründüğünü belirleyen stil kuralları
Açıklama:State, bir component'in sahip olduğu değişebilen veridir; değiştiğinde UI'ın bunu yansıtacak şekilde güncellenmesi beklenir. Sabit yazılmış sabitler (a) hiç değişmez, dolayısıyla state değildir; stil kuralları (d) ise görünümü tarif eder, view'ın arkasındaki veriyi değil.
State ManagementZorluk 2
Component tabanlı UI'larda state ile props arasındaki fark nedir?
  • aState parent'tan geçilir; props ise component'in kendi içinde yaratılıp değiştirilir
  • bState ve props aynı şeyin iki adıdır; ekipler yalnızca convention gereği birini seçer
  • cState, bir component'in sahip olduğu ve değiştirebildiği veridir; props ise dışarıdan geçilen değerlerdir✓
  • dProps zamanla serbestçe değişir; state ise component ilk yaratıldığında sabitlenir
Açıklama:Bir component state'ine sahiptir ve onu değiştirir; props ise parent'tan verilen girdilerdir ve child tarafından yeniden yazılması beklenmez. (a) şıkkı iki tanımı ters çevirir; (d) ise tam tersidir — state, zamanla değişmesi beklenen kısmın ta kendisidir.
State ManagementZorluk 2
// items mevcut state (bir liste)
function addItem(items, newItem) {
  items.push(newItem)   // aynı array'e ekle
  return items
}

UI, yeniden render edip etmeyeceğine reference karşılaştırarak (old === new) karar veriyor. Liste ekranda neden güncellenmeyebilir?
  • apush aynı array'i mutate eder; eski ve yeni reference aynı olur, kontrol değişiklik görmez✓
  • bpush yeni uzunluğu döndürür, bu yüzden fonksiyon liste yerine bir sayı döndürür
  • cBir fonksiyondan array döndürülemez, bu yüzden UI'a boş bir değer gelir
  • dpush yepyeni bir array üretir; eski reference'lar geçersiz olup düşer
Açıklama:Yerinde mutate etmek aynı array reference'ını korur; reference kontrolü (old === new) o zaman "değişiklik yok" der ve yeniden render'ı atlar. Çözüm yeni bir array döndürmektir, örn. return [...items, newItem]. (d) şıkkı push'un yaptığının tersini iddia eder — push var olan array'i mutate eder, yenisini yaratmaz.
State ManagementZorluk 1
"Prop drilling" terimi neyi anlatır?
  • aBüyük bir component'i, daha küçük ve daha dar odaklı birkaç component'e bölmek
  • bBir component'e geçilen değerleri, component onları kullanmaya başlamadan önce validate etmek
  • cBir component ekranda ilk belirdiği anda sunucudan veri yüklemek
  • dVeriyi, onu kendisi kullanmayan birçok ara component üzerinden aşağıya geçirmek✓
Açıklama:Prop drilling, derin bir child'a ulaşmak için bir değeri yalnızca aktaran component katmanlarından geçirmektir; aradaki component'ler veriyi kullanmaz ama iletmek zorundadır. Component'i bölmek (a) ilgisiz bir decomposition'dır; girdileri validate etmek (b) ise tamamen ayrı bir konudur.
State ManagementZorluk 2
İki kardeş (sibling) component tek bir değerde senkron kalmalı: bir filter dropdown'ı ve bir sonuç listesi. Bu değer nerede durmalı?
  • aİki sibling'da da çoğaltıp her değişiklikte kopyalayarak senkron tutmak
  • bTüm component'lerin dışında, üst seviye bir değişkende tek bir global mutable değer olarak tutmak
  • cEn yakın ortak parent'a taşıyıp (lift) iki sibling'a da aşağı geçirmek✓
  • dDeğeri dropdown içinde tutup listenin dropdown'ın internal state'ine uzanmasına izin vermek
Açıklama:İki sibling bir değeri paylaşmak zorundaysa standart hamle, state'i en yakın ortak ataya taşımak (lift) ve aşağı geçirmektir; böylece tek bir sahip ve tek bir source of truth olur. Çoğaltmak (a) iki kopyanın senkrondan çıkmasına yol açar; başka bir component'in internal state'ine uzanmak (d) ise onun encapsulation'ını bozar.
State ManagementZorluk 3
Bir cart items'ı state'te tutuyor. Developer ayrıca totalPrice'ı da state'te tutup 'add item' handler'ında güncelliyor. Sonradan eklenen 'remove item' yolu ise totalPrice'a dokunmayı unutuyor. Alttaki tasarım problemi nedir?
  • atotalPrice items'tan türetilebilir; ayrı tutmak ikisinin senkrondan çıkmasına yol açar✓
  • btotalPrice floating-point yuvarlama hatalarından kaçınmak için string olarak tutulmalıydı
  • cCart state'te çok az şey tutuyor; gösterdiği her değer de açıkça state'te tutulmalı
  • dState asla sayı tutmamalı, yalnızca ham item'ları; yani totalPrice yanlış tip
Açıklama:Var olan state'ten hesaplanabilen bir değer (total = item fiyatlarının toplamı) state'te tutulmamalı, render sırasında türetilmelidir; çünkü ikinci bir saklanan kopya elle tutarlı tutulmak zorundadır ve eninde sonunda kayar — burada olan tam da budur. (c) şıkkı ters dersi verir: daha fazla türetilmiş değer saklamak senkron problemini çözmek yerine çoğaltır.

Uzmanlığa göre

Angular 450JavaScript 450React 450TypeScript 450Vue 450

Kıdeme göre

Frontend JuniorFrontend MidFrontend Senior

Diğer alanlar

BackendFullstackDevOps / CloudAI EngineerVeritabanıMobilGüvenlikQA / Test OtomasyonuData EngineerOyun GeliştirmeML Engineer

2925 soruluk Frontend bankasında kendini sına.

Mülakata başla