Question on get_it/injectable

[mboyamike]

I'm curious about the need for get_it/injectable. I understand they are service locators and quite popular within the community, and used it a bit, but I question it's need. Seems we are going for bloc, what advantage does using getit/injectable have over using repository providers and bloc providers? An example of this is here

[MillerAdulu]

From how I see it, from the example above as to why, as a project scales registering the repositories in the widget becomes quite disorganised.

Example: https://github.com/VGVentures/spacex_demo/blob/main/lib/app/app.dart

What happens when you have 10+ repos, depending on the size of the project? It gets more mangled up when you need to inject a repository into a cubit/bloc when it needs to be used in multiple places. See (https://github.com/VGVentures/spacex_demo/blob/main/lib/rockets/view/rockets_page.dart) for an example.

Injectable, in my view looks like unnecessary complexity (I am open to having my mind changed). However, get_it allows for the registration to happen in a straightforward manner. Also for the sake of disclosure, this is my preferred method. Here's an example of this in play.

final getIt = GetIt.instance;

class Singletons {
  static void setup() {
    getIt
      ..registerSingleton<HiveService>(HiveServiceImpl())
      ..registerSingleton<LocalDBService>(LocalDBServiceImpl())
      ..registerSingleton<AuthService>(AuthServiceImpl())
      ..registerSingleton<MissionService>(MissionServiceImpl())
      ..registerSingleton<NotificationService>(NotificationServiceImpl())
      ..registerSingleton<SoulService>(SoulServiceImpl())
      ..registerSingleton<DebriefService>(DebriefServiceImpl())
      ..registerSingleton<LMSService>(LMSServiceImpl())
      ..registerSingleton<SocketService>(
        SocketServiceImpl(localDBService: getIt()),
      )
      ..registerSingleton<StudentService>(StudentServiceImpl());
  }

  static List<BlocProvider> registerCubits() {
    return <BlocProvider>[
      BlocProvider<SigninCubit>(
        create: (context) => SigninCubit(
          authService: getIt(),
          hiveService: getIt(),
          socketService: getIt(),
        ),
      ),
      BlocProvider<RegisterStudentCubit>(
        create: (context) => RegisterStudentCubit(
          authService: getIt(),
        ),
      ),
      BlocProvider<SignOutCubit>(
        create: (context) => SignOutCubit(
          hiveService: getIt(),
          localDBService: getIt(),
        ),
      ),
      // ....
    ];
  }
}

Then initialize as follows:

  Singletons.setup();

  await bootstrap(
    () => MultiBlocProvider(
      providers: Singletons.registerCubits(),
      child: const App(),
    ),
  );

To use in a widget.

// Call the cubit/bloc
PrimaryButton(
  onPressed: () {
    context.read<SigninCubit>().signIn(
          email: _emailController.text.trim(),
          password: _passwordController.text.trim(),
        );
  },
  title: 'Sign In',
)

// Call an API to load results
class _EnquiriesPageHandsetState extends State<EnquiriesPageHandset> {
  @override
  void initState() {
    context.read<GetStudentEnquiriesCubit>().getStudentEnquiries();
    super.initState();
  }
  // ...
}

In this format, everything is set up in one place and you don't need to run injections in widgets and the definitions are straightforward.

[MillerAdulu]

@SiroDaves,

Kindly pass by here for us to have the discussion around injectable as we are considering moving away from it. Would appreciate your input.

[SiroDaves]

On it

[SiroDaves]

While I understand and respect your perspective, I'd like to explain why I prefer using injectable in this project, as well as in other projects I maintain or contribute to. For me, injectable serves as a convenient code generator for get_it, which I find to be an essential tool in project development. Here are my main reasons:

• Automatic Code Generation: injectable automatically generates code for dependency injection, reducing boilerplate and minimizing manual errors in registration.

• Clear Dependency Management: Dependencies are clearly defined with annotations like @singleton, making it easy to understand their lifecycle and scope, enhancing project organization.

• Scalability and Maintenance: As projects grow, injectable simplifies dependency management, keeps code organized, and reduces bugs by following best practices.

Now that I have given you the reasons I will proceed on how to use it.

1. Add the necessary dependencies to the pubspec.yaml:

   dependencies:
     injectable: ^1.0.0
     get_it: ^7.0.0
   
   dev_dependencies:
     injectable_generator: ^1.0.0
     build_runner: ^2.0.0

2. Create a Configuration File at lib/core/di/injectable.dart:

   import 'dart:convert';
   
   import 'package:dio/dio.dart';
   import 'package:flutter/foundation.dart';
   import 'package:fluttercon/core/di/injectable.config.dart';
   import 'package:get_it/get_it.dart';
   import 'package:injectable/injectable.dart';
   import 'package:shared_preferences/shared_preferences.dart';
   
   final getIt = GetIt.instance;
   
   @InjectableInit(
     initializerName: 'initGetIt',
     generateForDir: ['lib'],
   )
   Future<void> configureDependencies() async {
     await getIt.initGetIt();
     await getIt.allReady();
   }
   
   @module
   abstract class RegisterModule {
     @singleton
     @preResolve
     Future<SharedPreferences> prefs() => SharedPreferences.getInstance();
   
     @singleton
     Dio dio() => Dio();
   }
   
   dynamic _parseAndDecode(String response) => jsonDecode(response);
   
   dynamic parseJson(String text) =>
       compute<String, dynamic>(_parseAndDecode, text);

3. Use annotations to define how your classes should be registered in the service locator.

   @singleton
   class HomeBloc {
     // Bloc implementation
   }

4. Generate the Code needed by running:

   dart run build_runner build --delete-conflicting-outputs

   This command generates all the required code to register your dependencies automatically, saving you time and effort.

5. Initialization: Initialize the dependencies in the main entry point of your application.

   void main() async {
     WidgetsFlutterBinding.ensureInitialized();
     await configureDependencies();
     runApp(MyApp());
   }

As highlighted, using injectable leads to a more organized and maintainable codebase. Its automatic generation of dependency registrations simplifies the process, ensuring consistency and adherence to best practices—essential as your project grows. This setup centralizes dependency management, making refactoring and scaling easier while avoiding scattered and potentially conflicting manual registrations.

I introduced injectable to our team at work, and they appreciated the convenience it brings to our workflow.

[MillerAdulu]

Are you able to go further into how this will be used with respect to blocs/cubits that would need say RegisterModule injected into them?

[MillerAdulu]

An example of the BLoC/Cubit being used in a widget would be appreciated to help finalise this discussion.