📦 Packages

💕 My packages

• ws
• platform_info
• l
• pubspec_generator
• octopus
• multiline
• control
• xor_cipher
• spinify
• throttling

👍 Recommended packages

Recommended packages with the highest levels of quality.

• firebase
• drift
• meta
• json_serializable
• shared_preferences
• collection
• async
• characters
• web
• stream_transform
• rxdart
• url_launcher
• dart_code_metrics
• icons_launcher
• flutter_native_splash
• flutter_gen_runner
• intl
• pigeon
• http
• path
• rive
• path_provider
• flutter_local_notifications
• geolocator
• connectivity_plus
• share_plus
• image_picker
• file_picker
• sentry & sentry_flutter
• sensors_plus
• battery_plus
• cached_network_image
• google_fonts
• permission_handler
• image
• flutter_blurhash
• animations
• animated_text_kit
• spine_flutter
• font_awesome_flutter
• theme_tailor
• shelf
• functions_framework
• just_audio
• video_player
• mockito
• clock
• fake_async
• feedback
• win32
• flame

👎 Not recommended packages

Packages that are not recommended for use, with implementation problems, lying in documentation or benchmarks, are initially problematic concepts.

• hive
• isar
• get
• get_storage
• get_it
• ferry
• flutter_hooks
• mobx
• riverpod
• hydrated_bloc
• easy_localization
• fpdart
• dartz
• serverpod
• dart_frog
• shimmer
• go_router
• auto_route
• mix

Hive

1. Lack of thorough testing: Compared to SQLite, Hive has significantly less testing, raising concerns about its reliability.
2. No built-in failure recovery: If a Hive database encounters an issue, it doesn't have a built-in mechanism to recover or fall back.
3. Complexity of queries: Simple key-value queries are straightforward, but anything more complex requires a significant amount of code.
4. Non-standard: Hive is not an industry standard and its implementation appears to be hastily put together.
5. Poor support and maintenance: The database seems to have been abandoned, and its maintenance is questionable.
6. No migration support: Any changes to models crash the application, and the only workaround seems to be deleting the entire database with each app version.
7. Mutable models: This can cause problems in a database.
8. Misleading documentation and benchmarks: Claims made in the documentation and benchmarks don't match the actual performance.
9. Performance issues: Hive is significantly slower than SQLite.
10. Small community: Hive's community is much smaller compared to SQLite's, leading to less support and fewer resources.
11. Memory management issues: Hive keeps all data in memory, which can cause issues for larger datasets. And absolutely the worst solution for caching.
12. Hardcoded adapters and keys: This makes the code hard to follow and maintain.
13. No synchronization between isolates: Attempting to interact with the same box across isolates leads to a crash and the application stuck, even after restart
14. Poor code generation: The autogenerated code is difficult to work with, making JSON storage or protobufs in shared_preferences seem like better alternatives.
15. Lack of database features: Hive lacks key database features like relations, foreign keys, joins, triggers, virtual and generated fields, views, and temporary tables. Lack of support for handling JSON or in-database search functionality. And many many features of SQLite.
16. The complexity of testing: Testing Hive databases is non-intuitive compared to SQLite where a :memory: database can be used.
17. No field indexes: Any non-key-based queries require full database scans.
18. No transactions: Hive does not support transactions, making it unsuitable for financial applications.
19. Reliability issues: Due to many of the above reasons, Hive's reliability is questionable.
20. Limited external software support: There's a lack of tools to interact with Hive, hindering inspection and design of the database.
21. Non-transferable experience: Due to its non-standard nature and project abandonment, time spent learning Hive could be considered wasted, with limited transferable knowledge or benefits to one's career.

Isar

Isar is developed by the same author as hive. In general, it is based on Rust, which has bindings to a C library called libmdx. This statement alone sounds odd, as Dart has FFI and can use this library without using superfasta Rust at all. Then many, if not all, of the points about Hive also apply to isar. Also it much slower than SQLite at almost all real cases.

getx

GetX is a library for Flutter that tries to combine everything in one package like navigation, state management, storage, etc. Therefore, it is usually considered as a framework. However, everything is not so good. Even an idea to combine all the stuff is mad from the beginning. Moreover, the source code is awful. It has a lot of bugs, not only talking about the documentation, coverage, etc. On top of that, there is no single approach to writing the code. In addition, the idea of how to manage the logic\business logic and all the stuff is completely non-engineering. That is why projects that use this lib are very difficult to maintain. Hence many problems arise. It becomes really tough to produce new features, releases.

get_it

Service locator with all the problems that come in. Basically, you register your objects on the map and access them throughout the app. Obviously, having the possibility to access any object wherever you want from any place is a destructive idea. For example, you can pull one entity out of a completely different layer and/or location in the application, change its state, dispose of resources, and so on. Even if you know it's not good to do that, it still doesn't prohibit you from doing it, or juniors with less experience. Moreover, in such cases, it's better to have global variables, because they will be more understandable. To summarize, you deprive yourself of a clear dependency injection, moreover, you are likely to violate the principle of dependency inversion. If you still need the get_it, then I would recommend you to use injectable.
All in all, constructors are the best way to inject dependencies. In Flutter, you can use BuildContext to inject dependencies. And data class is the best way to create your own container for dependencies.

ferry

GraphQL codegen for Dart and Flutter. Generally, it is usable, but generates a lot of code. It can happen that at some point the time spent on codegen and build will be more than a few hours, or even not work at all. Moreover, using this package is fraught with the fact that the size of your application will also be increased by huge numbers, 20-60 megabytes

flutter_hooks

Hooks are only pointless tricks, imposing their own rules and complicating the flow. Also, the creation of subscriptions and animations will be greatly complicated. To summarize, this package will not make your life easier, you will not write code faster, on the contrary, you are more likely to have difficulties. I would advise you to use snippets instead and a more Flutter way with StatefulWidget and State.

mobx

MobX is a reactive state management library. You are likely to have many implicit subscriptions that cause rebuilds. I'd suggest using bloc or ChangeNotifier & ValueNotifier instead.

riverpod

Riverpod is a kinda popular library for state management. It is based on global variables that store state. Let alone creating a bunch of global variables, it is also a bad idea to store state in global variables. Moreover, it is not easy to test.

hydrated_bloc

Hydrated Bloc is a library that allows you to persist bloc state. It is a bad idea to persist state. It is better to persist data, but not state. For example, you emitted an error or loading state. It was persisted. Next time, when the user opens the app they will see an error or loading state.