Get_it best practice about get_it

[escamoteur]

I typically have a file backend.dart like this here

import 'package:aartos/services/rtsa_service_.dart';
import 'package:aartos/services/rtsa_service_impl.dart';
import 'package:get_it/get_it.dart';

export 'package:aartos/services/rtsa_service_.dart';


GetIt backend = GetIt();


void initBackend()
{
  backend.registerSingleton<RTSAService>(RTSAServiceImplementation());

  backend<RTSAService>().init('192.168.178.91', 54664);
  //backend<RTSAService>().init('clabuster.dyndns.org', 54664);
}

And I call initbackend from mainbefore runApp you can do the same from your tests

Also don't over engineer its an App. A global is perfectly fine

[escamoteur]

@Daghis What would you gain? You would still need to import the filer where the GetIt class is defined.

[cosinus84]

https://github.com/escamoteur/flutter_weather_demo/blob/using_service_loactor/lib/service_locator.dart

[jimzenn]

Same question here, @cosinus84 are you sure this is the best practice?

[escamoteur]

You only declare on global viable for the servicelocator and use it everywhere

[Daghis]

I just started looking at using this to handle some of my dependency management. It appears that it'll make it much easier to mock services used by the code being tested. (Note that I'm new to Dart and Flutter, so I'm speaking with minimal experience in that world.)

That said, I have a question about the need to use a global variable. Do you think it would be appropriate instead to have a shared instance that could then be referenced directly from the class as a static method? For example, one could have GetIt.getInstance().get<Firestore>() which would have the same effect without requiring importing a Dart file just to get access to its global variable.

Also, if one does this, one could have a private class field as a short cut like GetIt _getIt = GetIt.getInstance();.

I'm not sure that this is necessarily a better practice than what's recommended, but it came to mind while starting to use this package.

[Daghis]

That is a very valid question to which I'm not sure I have a good answer. Part of that is a lack of understanding of how things are done best in Dart (coming from a Java background).

In my limited experience, I had defined the getIt global variable in my lib/main.dart, so it seemed undesirable for my test files to import that (although it doesn't seem to cause any actual problems). Now, the obvious solution would be to create a separate Dart file that contains any such commonly used global declarations that could be included by lib/main.dart as well as the test files.

Now, this is one of the places where my Dart experience is significantly lacking. With Java, I believe that if I want to access a GetIt method, not only would I have to import the file defining the global variable, I'd also have to import the GetIt class to get the method definitions. It seems that with Dart, that part isn't necessary. In that case, I'm really not sure there is any functional advantage, although perhaps there might be a stylistic one. Again, though, that comes from a non-Dart perspective.

[Daghis]

That sounds perfectly fine! Thank you very much for your help and input.

[mulderpf]

I have just spent the weekend implementing Get It into my project and I couldn't be happier with what it has done for my code structure. I've written a bunch of widget tests and they all work well...in isolation. When I run all of the tests, a few of them start interfering with each other (because everything is using the same singleton instances) - I cannot think of a way in which to isolate them from each other (for example, one is a mock of a data store and I want to test different combinations of data going back to my app for the same calls).

EDIT: This wasn't really a get_it issue, but rather what was happening was that I wasn't cleaning up after my own tests. Leaving the question and resolution here for anyone who comes across this and wants to blame the wrong thing.

[venkata-reddy-dev]

@escamoteur can you close this if there is no action or changes required from the package side.

i hope best practiced are already included in Readme file

[escamoteur]

Actually I haven't included this directly. But this issue is sort of a place we're people can ask questions on best usage. Am 10. Apr. 2024, 17:02 +0200 schrieb Venkata Reddy ***@***.***>:

…

@escamoteur can you close this if there is no action or changes required from the package side. i hope best practiced are already included in Readme file — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: ***@***.***>