I’m working on breaking down a large Flutter monolith into smaller, independent packages for better modularity. However, I’ve hit challenges in these areas:
-
Database:
How do you share a database (e.g., SQLite, Hive) across multiple packages without tight coupling? -
Notifications:
What’s the best approach to handle push notifications across independent packages? -
Navigation:
How can navigation be managed efficiently between decoupled packages without losing modularity? -
Global state (BLoC):
How do you handle shared state across packages using BLoC, or should each package manage its own state?
Looking for advice on best practices or patterns that worked for you. Thanks!
For Navigation, I’ve tried to make own router for every package, which will be responsible for the routing in that package.
For GlobalState, I’ve tried to export every BLoC from every package and aggregate them in the mainApp, and then get the instance via Provider.
But the packages are still coupled to each other.
2
Answers
I’m writing this as an answer because it’d be too clumsy as comments.
From an SO perspective you’ve got 4-5 questions here, you might want to explore them individually 🙂
I know nothing about Flutter and Dart specifically, but it sounds like there’s lots of technology agnostic architecture and system design ideas that could be applied to improve the objective nature of the code base. It’s hard to provide specifics given the high-level nature of your question.
Some general things to consider:
Packages & State
Just in case you are not familiar with layers & layering in an application, generally speaking things within a layer can talk to one another. I’m not sure if in your case a package is a logical group (i.e. cohesive group) of classes within one layer – or more like a Vertical Slice (cuts across several layers).
If for you, package == vertical slice, then I think typically each package would deal only with it’s own state. Be aware that sometimes concepts are shared between slices/packages – say at the database level, and therefore there might not be a simple clean way of saying something is in one package or another. All I can say is to be pragmatic and apply the KISS principle if you are in doubt.
Prototype First
One piece of advice, if you are applying new ideas to a large code-base, consider prototyping them out first, so that you can better ensure that:
Keep in mind that sometimes you might be able to prototype an idea in a small test-harness, but other times you might want to take a snapshot of the entire code base and trial the change. I.e. a "throwaway" version of the code. I usually find that the first time I do something is not the best.
The short answer is
But I recommend you to read the above answer really it’s informative and helpful