well... i'm not developing any ui yet i'm testing only the backend, and i don't like the idea that in supabase_flutter there are widgets. I really think it's a bad idea because it ties the backend to the UI. It's a kind lock in.

Do you mean the different

AuthState

widgets?

yes, all the supabase UI witdgets in general. I mean.. supabase is a backend, i don't feel like mixin' it with the UI. but supabase_flutter has some things, not related to UI like the handling of persising session, which is not implemented in the supabase_dart. Dunno, it feels a bit messy. I'ld rather prefer only one package, with all the functionalities, without UI widgets

The widgets are removed in a future version: https://github.com/supabase-community/supabase-flutter/pull/124

@Vittorio.Paragallo I do not like those widgets as well and I am glad that they are removed (or will be removed). I understand why you'd want to keep your UI away from the business logic but if you are just beginning and learning something new, I'd day that these "good" principals do not matter as much. Make mistakes and learn good coding practices along the way. At least that was the case for me. That being said, I use riverpod for state management and dependency injection. Although I know the basics of bloc, I hope to use it and learn it through a proper project later on. For now, I am happy with riverpod. You can easily implement an MVC or MVVM approach with riverpod where your intermediary C or VM classes talk to UI and Business logic separately. Again, it's entirely your choice. I also like that riverpod comes out of the box with built-in stream and future providers which have the three default stages - loading, error and data where I can map a certain UI element to each state. It's really really convincing and lets me focus more on my business logic and less on state management and UI issues.