chore: refactoring to `bloc` advices needed about bloc

[FarisArmoush]

Overall this looks amazing, the only thing I would improve is SpotBlocWidget, I would separate into two widgets to separate the injection logic from the UI logic, so it would look something like this :

class SpotBlocView extends StatelessWidget {
  final LatLon location;

  const SpotBlocView({super.key, required this.location});

  @override
  Widget build(BuildContext context) {
    return BlocProvider(
      create: (context) =>
          SpotCubit(SpotRepository())..loadSpotInfoAndReviews(location),
      child: SpotBlocWidget(),
    );
  }
}

class SpotBlocWidget extends StatelessWidget {
  const SpotBlocWidget({super.key});

  @override
  Widget build(BuildContext context) {
    return BlocBuilder<SpotCubit, SpotState>(
      builder: (context, state) {
        if (state is SpotLoading) {
          return const CircularProgressIndicator();
        } else if (state is SpotLoaded) {
          return Column(
            children: [
              Text(location.toString()),
              Text(state.info.isPublic.toString()),
              Text(state.reviews.length.toString()),
            ],
          );
        } else if (state is SpotError) {
          return Text(state.message);
        } else {
          return const Text('Something went wrong');
        }
      },
    );
  }
}

[ksyro98]

@ethicnology hey, sorry for the delayed response.

The DataProvider has nothing to do with the Provider package and with StateManagement, it's an unfortunate naming convention.

And yes, I agree with you, moving all those methods (and caching) to the provider is a good idea. It will keep your models lighter, and will help with separation of concerns.

In general a DataProvider's role is to communicate with the external sources (databases, servers, local storage, etc) and to return raw data. Then you usually have a Repository that takes those raw data and converts them to Models for your application. And then the Bloc/Cubit and UI work with these Models just like you have done in your code.

[ksyro98]

hey!
overall it looks good to me

i'm a bit skeptical about the SpotInfo.get and SpotReview.get methods
are you doing a network request in them (or somehow communicating with external resources)?

if yes, following the BLoC principles, I would recommend placing those requests in a DataProvider class
you can read more about it here: https://bloclibrary.dev/architecture/#data-provider

[ethicnology]

Thanks for your advice @ksyro98

Yes SpotInfo.get and SpotReview.get represents database tables and functions to access the related data.

Does DataProvider has anything to do with Provider package and StateManagement ?

Should I create first in models the class without database functions and then in providers functions to access the data get add that may wrap select insert and caching when needed ?