Question 1

Provider, Riverpod və BLoC-u müqayisə edin.

Accepted Answer

Müqayisəni ölçülərə bölün, üstünlük siyahısına deyil. Mexanizm: üçü də eyni Flutter təməli üzərindədir. Provider InheritedWidget üzərində örtükdür; flutter_bloc BlocProvider-i package:provider ilə həyata keçirir; Riverpod da ProviderScope vasitəsilə ağaca bağlanır. Deməli performans fərqi mexanizmdən gəlmir. Provider-in yeri: ağacda (Provider, BLoC) vs ağacdan kənarda qlobal final (Riverpod). Buradan Riverpod-un kompilyasiya vaxtı təhlükəsizliyi və eyni tipdən çox provider imkanı çıxır. Async state: Provider-də əl ilə bayraqlar; Riverpod-da AsyncValue hazır; BLoC-da state modelində status enum ya sealed siniflər. Test: Riverpod-da overrides ilə asılılığı əvəz etmək bir sətirdir; BLoC-da blocTest state ardıcıllığını deklarativ yoxlayır (seed, expect, wait, verify); Provider-də ağacı əl ilə qurmaq lazımdır. İzlənilə bilənlik: BLoC-un onTransition-ı state → event → state zəncirini verir — audit üçün ən hazır forma. Concurrency: BLoC-da EventTransformer və bloc_concurrency (droppable, restartable) hazır gəlir; digərlərində əl ilə yazılır. Yekun cümlə: "Seçim mexanizmə görə deyil, komandanın ehtiyacına görə edilir — async payı, audit tələbi, test mədəniyyəti və öyrənmə xərcinə görə."

Question 2

Sizin seçdiyiniz yanaşmanın zəif tərəflərini deyin.

Accepted Answer

Bu sual özünütənqid qabiliyyətini yoxlayır. "Zəif tərəfi yoxdur" cavabı ən pis variantdır. Riverpod seçmisinizsə: yeni mental model (provider-lərin qlobal final olması ilk baxışda qlobal state kimi görünür), codegen build vaxtı, autoDispose/family qaydalarını bilmədən yaddaş və cache səhvləri, major versiya keçidlərinin (2 → 3) əlavə işi. BLoC seçmisinizsə: boilerplate (event, state, handler ayrıca fayllar), sadə ekranlar üçün həddindən artıq struktur, state ardıcıllığına bağlı testlərin kövrəkliyi, komandada disiplinin olmaması halında "event adları qarışıq" problemi. Provider seçmisinizsə: async state əl ilə yazılır, runtime xətaları (ProviderNotFoundException), ChangeNotifier-in mutable dizaynı select optimizasiyalarını sındırmağa imkan verir, BuildContext-dən asılılıq (dialoq, route halları). Hər zəiflikdən sonra necə azaltdığınızı deyin: lint qaydaları, nümunə feature, code review checklist, testlə örtmək. Bu, cavabı şikayətdən mühəndis mövqeyinə çevirir.

Question 3

Müsahib deyir: "Bizdə hər şey GetX ilə yazılıb." Nə cavab verərdiniz?

Accepted Answer

Bu, həm texniki, həm mədəni sualdır — məqsəd sizin komandaya necə qoşulduğunuzu görməkdir. Struktur: 1. Maraq göstər, tənqid yox: "Hansı hissədə istifadə olunur — state, naviqasiya, DI, hamısı? Komanda hansı problemlərlə rastlaşır?" 2. Öyrənmə hazırlığını bildir: mövcud yanaşmada məhsuldar olmaq birinci vəzifədir; heç bir komanda yeni işçidən "gəlib hər şeyi dəyişməsini" gözləmir. 3. Prinsipial mövqeyini kriteriyalarla ifadə et: mənim üçün vacib olan library adı deyil, state-in UI-dan ayrılması və test edilə bilənlikdir. Bu iki şey hər hansı yanaşma ilə mümkündür — və elə bu, mənim ilk töhfəm ola bilər. 4. Konkret dəyər təklif et: repository/service qatının state management-dən asılı olmayan saxlanılması, kritik axınlar üçün testlərin yazılması, qlobal statik girişlərin testlərdə izolyasiyası. 5. Gələcəyə açıq qapı: əgər komanda gələcəkdə dəyişiklik düşünürsə, ölçüləbilən kriteriya və pilot feature ilə qərar verməyi təklif edərdim. Bu cavab "GetX pisdir" mövqeyindən qat-qat güclüdür: mövcud koda hörmət, texniki prinsip və konkret töhfə birlikdə gəlir.

Sual	Provider	Riverpod 3	BLoC / Cubit
Öyrənmə əyrisi	Aşağı	Orta (yeni mental model)	Orta-yüksək (event/state disiplini)
Async state	Əl ilə bayraqlar	`AsyncValue` hazır	State modelində status/sealed
Səhv provider oxumaq	Runtime xətası	Kompilyasiya səviyyəsində görünür	Runtime xətası
Test: asılılığı əvəz etmək	Ağacı əl ilə qurmaq	`overrides` — bir sətir	`bloc_test`, `MockBloc`, `whenListen`
State ardıcıllığının testi	Əl ilə listener	`container.listen`	`blocTest(expect: ...)` — ən hazır forma
Audit / event jurnalı	Əl ilə	Observer-lər	`BlocObserver` + `onTransition`
Debounce / concurrency idarəsi	Əl ilə	Əl ilə (və ya `select`/`autoDispose` ilə dolayı)	`EventTransformer` + `bloc_concurrency`
DI üçün rəsmi tövsiyə	Rəsmi case study bunu seçir	Provider qrafı DI rolunu da oynayır	`RepositoryProvider` (daxildə provider)

Müqayisə və seçimin əsaslandırılması

📚 Mənbələr və sənədlər