Ամեն դեպքում պետք է օգտագործել Cubit նախագիծում?

Ոչ, ոչ միշտ։ Կառավարման վիճակի ճարտարապետության ընտրությունը կախված է նախագծի բարդությունից, թիմի չափից և ծրագրավորողների նախընտրություններից:

Ալտերնատիվներ Cubit-ի համար են՝

• setState: հարմար է պարզ վիդջեթների համար տեղական վիճակով:

  // Օրինակ `setState`-ի օգտագործման
  RaisedButton(
    onPressed: () {
      setState(() {
        _counter++;
      });
    },
    child: Text('Ավելացնել'),
  )
  

• Provider: թեթև լուծում կախվածությունների ներմուծման և հիմնական վիճակային կառավարման համար:

  // Օրինակ Provider-ի օգտագործման
  Consumer<MyModel>(
    builder: (context, myModel, child) {
      return Text('${myModel.data}');
    },
  )
  

• Riverpod: բարելավված Provider՝ ավելի հուսալի վիճակային կառավարման և թեստավորման մեթոդներով:

  // Օրինակ Riverpod-ի օգտագործման
  Consumer(builder: (context, ref, _) {
    final myValue = ref.watch(myProvider);
    return Text('$myValue');
  })
  

• BLoC (Business Logic Component): ավելի խիստ մոդել, որը կարող է ավելորդ լինել փոքր ծրագրերի համար։ Cubit-ը BLoC-ի պարզեցված տարբերակն է:

Հատկանիշներ	setState	Provider	Cubit	BLoC
Բարդություն	Ներքևային	Ներքևային-միջին	Միջին	Բարձր
Հարմար է համար	Տեղական	Պարզ/Միջին	Միջին/Բարդ	Բարդ
Թեստավորման կարողություն	Միջին	Լավ	Արտակարգ	Արտակարգ
boilerplate-կոդ	Ներքևային	Ներքևային	Միջին	Բարձր

Cubit-ը հիանալի է միջին և մեծ նախագծերի համար, որտեղ պահանջվում է տրամաբանական և UI-ի հստակ բաժանում, լավ թեստավորման հնարավորություններ և կանխատեսելի վիճակային կառավարման մեթոդներ։ Սակայն շատ պարզ նախագծերի համար setState կամ Provider-ը կարող են բավարար լինել և ավելի արագ իրականացնել։