I overhauled and updated an introduction to get_it
5 Likes
Really cool article!
I thought the description of “ambient variables” was really well-put: IMO the focus should be on performance/readability/testability of the codebase rather than whether or not any global variables are used.
My only criticism would be the example with AppModel([WeatherAPI weatherAPI = null]). Looks like that snippet still needs to migrate to null safety 
Currently I’m undecided as to my favorite state management approach, but I really like how get_it is easy to learn and a great way to reduce boilerplate without any need for code generation.
1 Like
Hi @nate-thegrate,
Thanks, I recommend checking out watch_it’s Readme to see how nicely it plays with get_it.
The line in question actually is correct, it’s meant to allow you to pass in an instance while testing if you do not want to use get_it while testing.
Or what do I miss there?
Yeah, I took a look at watch_it, and it seems to be very similar to flutter_hooks but a bit more simple, which is nice.
Sorry for not explaining my thoughts on the constructor very well! I was thinking something along the lines of:
AppModel([WeatherAPI weatherAPI = null]); // pre-null safety
AppModel([WeatherAPI? weatherAPI]); // Dart 3 compatible
(not a big deal, of course!)
Thanks, fixed.
Yeah watch_it uses the same principle as flutter_hooks but indeed I think its API is way nicer and the connection to get_it makes a nice full solution.
If you add flutter_command you have an even better solution.