Cześć!
Rozważam jaki sposób użycia jest poprawny w przypadku BLoC.
Załóżmy, że mamy w aplikacji ekran ustawień, gdzie użytkownik może:
W takim wypadku lepszym podejściem jest zrobienie jednego BLoC do obsługi wszystkich zdarzeń (n eventów i n stanów)? Czy 4 BLoC i wykorzystanie MultiBloc po stronie UI?
Tego się właśnie spodziewałem. Niestety mało kto piszę we Fluterze tutaj. Po drugie, moim zdaniem, BLoC to niepotrzebny boilerplate, który fajnie wygląda na tutorialach i ich przykładach, a w realnym projekcie nikt nie wie co pisać. Wydaje mi się, a miałem z tym styczność, że jeśli nie wiesz gdzie i jak zrobić BLoC to to się do twojego projektu nie nadaje. Pytanie dlaczego akurat BLoC? Nie da się tego rozwiązać zwykłym zapytaniem do API i FutureBuilder?
PS.
Ja miałem problem z BLoC'iem jak miałem formę, w której tworze, na przykład, nowy towar. Niby prosta rzecz, ale na formatkę potrzebujesz pobrać z API grupy towarowe czy jednostki miary i nikt nie był w stanie mi wytłumaczyć jak ten BLoC ma wyglądać, aby coś takiego ogarnąć. Stwierdziłem, że jeśli muszę się doszukiwać rozwiązania, albo łączyć dwa rozwiązania, bo BLoC jest dobry "tu", a coś innego jest dobre "tam", to znaczy, że to nie jest wartę czasu ✌
Dziękuję za Twoją opinię.
Osobiście używałem BLoC jako 1 na widok. Tam miałem obsługę wymaganych eventów.
Generalnie działało poprawnie, ale wiele razy było zbędne przebudowywanie UI, stąd zagwozdka jak to rozwiązać.
Zakładam, że masz doświadczenie we Flutterze, ja jestem stosunkowo świeży. Czy udało Ci się znaleźć optymalną bibliotekę do zarządzania stanem? Wykorzystujesz coś zamiast BLoC?
Nie jestem orłem we Flutterze. Mam kilka małych aplikacji, ale raczej też jestem początkującym. Wydaje mi się, że najciekawszym rozwiązaniem na tę chwilę jest GetX.
Moja laika opinia.
Powinien być na komponent A komponentem może być całą stroną albo tylko jeden widget. Np ikona z liczbą powiadomień czy wiadomości.
Ja z GetX mam czasem kontroler na stronę ale dla prostych crudow kontroler jest dla 2-3 stron (view, edit, new). Czasem strona ma kilka kontrolerów.
Nie używajcie GetXa - Why you should not use GetX?
BLoCa akurat nie używam osobiście, ale z tego co wiem to jest dobrym state managementem dla dużych projektów nad którymi pracuje wielu developerów, bo narzuca sztywne ramy i ciężko coś jest spaprać. Jego wadą natomiast jest duża ilość boilerplate'u. Jeżeli chcesz coś bardziej nowoczesnego i zwięzłego to polecam riverpoda od Remiego - twórcy providera, który go nazwał providerem v2.
U mnie w projekcie w widoku nie ma żadnej logiki, logika aplikacji siedzi w controllerze który jest StateNotifierem, który znowuż jest eksponowany w widoku przez StateNotifierProvidera. I jestem bardzo zadowolony z tego podejścia :)
@Inclouds: Ale z tych zastrzeżeń nic nie jest istotne (chyba) jeśli tylko używasz GetX do state management.
@jacek.placek: jeżeli nie testujesz swojego kodu to faktycznie nic nie jest istotne ;)
Misiu, nie spinaj się za mocno. :) Problemy z testowaniem nie dotyczą wszystkich części GetX.
The correct way to use GetX
If you are planing to use GetX for your project use only the necessary features like state management, reactive programing and dependency injection. Try to avoid the GetX navigation and bindings to prevent red screen errors.
@Inclouds: Może teraz riverpod ma coś więcej, bo próbowałem dawno temu i na tę chwilę tylko GetX był w stanie spełnić moje "wymagania". Ten artykuł jest dziwny. To tak jakby kupić smarfon i oburzać się, że ma więcej funkcji niż dzwonienie. Skoro jest get_connect to czemu tego nie użyć? Takie Dio to tragedia i omijam szerokim łukiem, bo do tej pory są problemy. Chyba dobrze, że jeden z modułów w pełni ogarnia REST i GraphQL, bo po co to rozdzielać?
Nie chce mówić, że artykuł głupi, bo każdy ma prawo wyrazić swoją opinie i w pewnych kwestiach się zgodzę, ale żeby cały swój świat stawiać na bazie jednego wpisu w necie o "wadach" GetX to już jest lekka przesada. Chyba, że od samego początku miałeś zatarcia z tą biblioteką i teraz tylko masz "potwierdzenie", argument, że jest tak jak myślisz.
@AdamWox: A skąd teoria, że wyrabiam sobie opinię o GetX na podstawie jednego artykułu w necie? Tu masz całą dyskusję na reddicie - Reddit GetX
Czego Ci brakowało w riverpodzie i jakie problemy miałeś z Dio? Pytam, bo obecnie używam do RESTa dio z retrofitem i śmiga :)
Chciałem użyć riverpoda może z rok temu w apce i szczerze mówiąc dokładnie nie pamiętam co było z nim nie tak. Ogólnie przejście na GetX rozwiązało te "problemy", ponieważ aplikacja żyje do teraz. W kwestii Dio to miałem problem z timeout'ami, oraz wyjątkami (statusCode 500). Nawet dodanie
validateStatus: (status) {
return status != null && status < 500;
}
kompletnie nie pomaga i aplikacja na statusCode 500 się wywalała mimo iż po stronie serwisu jest pierdyliard ifów w tej kwestii + to co wyżej napisałem. Aktualizowałem Dio, aktualizowałem całego Fluttera i musiałem to trochę inaczej ogarnąć po stronie API. Błąd ten powodował, że aplikacja wysyłała w kółko ten sam dokument do API i było masa duplikatów. Tydzień temu poczytałem o Dio
http vs dio, bo zaczynam nowy projekt i już nie chciałem popełniać tych samych "błędów".
Co do riverpod pewnie też spróbuje w nowym projekcie jako drugie podejście. Te całe Momentum też zapowiada się dobrze, ale za młody projekt i chyba też zmierza do bycia do wszystkiego jak GetX.
Bo być może za bardzo kombinujcie. Im więcej bibliotek 3rd party tym większa szansa na błędy. Ale co do dio to się zgodzę, ma swoje problemy.
Miałem podobny problem ze statusami serwera i musiałem zrobić coś takiego:
Dio()..options.validateStatus = (status) => true
A to dlatego, że walił wyjątkami z d**y i nie było wiadomo jaki błąd z serwera poleciał, a musiałem to wiedzieć. W szczególności musiałem wiedzieć, że jest 401, czyli użytkownik podał złe dane logowania
ja korzystam z bloca i nie narzekam. Boilerplate nie jest taki straszny - po 1 są wtyczki np. do VSCode, które wszystko generują, po 2 - jest Freezed, który generuje unie. Jeśli chodzi o sam problem to raczej zakładałbym 1 bloc per usecase. Np. mamy logowanie więc masz logowanie, rejestracja, wylogowanie, logowanie np. przez google. Wszystko to zawarłbym w jednym blocu.
Zdarzają się czasami bloc'i per widget, per screen - imo nie ma tu jakiejś sztywnej zasady. Wszystko zależy od tego czego pottrzebujesz. Zacząłbym jednak od podejścia 1 bloc per usecase/grupa funkcjonalności (auth, crud etc)
ps. polecam zapoznać się z tym tutorialem. Ma już trochę ale myślę, że dużo da się z niego wyciągnąć i wyznaczyć jakiś swój styl pisania apk.
Twój bloc per usecase nie ma odzwierciedlenia na "zaawansowanych" formach. Chociażby mój przykład z dodaniem kartoteki towaru, trzeba pobrać z API jednostki miary i grupy towarowe, a osobno jest bloc na dodawanie danych słownikowych jak jednostki miary i grupy towarowe 
Do prostych crudów typu todo list jest ok, do większych projektów to jest to kompletna strata linijek kodu, nawet jeśli VS Code ma wtyczkę, która większość klepnie za mnie.