Say Goodbye to Callback Chaos – Meet event_handeler: The Simplest Way to Pass Data in Your Flutter App
You’re building a Flutter app. It’s going well… until you need to send data from one part of your app to another — maybe even across pages, screens, or widgets that don’t even know each other.
Suddenly you’re knee-deep in InheritedWidget, Provider, Riverpod, or — dare we say it — global variables.
Hold up! There’s a simpler, more elegant way.
Meet event_handeler — a tiny yet powerful event bus-style package that’s here to save you from state-sharing madness.
What is event_handeler?
In short: it’s a tiny event manager that lets you dispatch and listen to events globally in your Flutter app — kind of like a walkie-talkie system between widgets.
- No setup overhead.
- No complex state management.
- No global variables.
- Works anywhere — across screens, widgets, even async flows.
Just call dispatchCustomEvent() from anywhere, and listen to it from anywhere else. That’s it.
✨ Why You’ll Love It
- ✅ Simple API — dispatch and listen, just two methods.
- ✅ Global Scope — works across screens and widgets.
- ✅ Memory-Safe — supports
.cancel() and one-time listeners.
- ✅ Pure Dart — no native plugins, works everywhere Flutter does.
- ✅ Fun to use — you'll feel like a wizard shouting spells across your app.
Quick Start
Add it to your pubspec.yaml:
dependencies:
event_handeler: ^latest_version
Real-World Use Cases
1. Send Data Between Screens Without Navigation Params
// Page A
dispatchCustomEvent("Hello, Screen B!", "greeting");
// Page B
addCustomEventListener("greeting", (message) {
print("Received message: $message");
});
Boom — instant cross-page communication without a single Navigator.push argument.
2. React to Global Events from Anywhere
Imagine toggling dark mode or showing a global toast from anywhere:
dispatchCustomEvent(true, "darkModeToggle");
// In your top-level widget or settings controller
addCustomEventListener("darkModeToggle", (isDarkMode) {
MyThemeController.setDarkMode(isDarkMode);
});
3. Trigger Animations, Refreshes, or State Changes Without Props
You want a widget deep in your tree to refresh? Just shout an event:
dispatchCustomEvent(null, "refreshFeed");
// Feed widget
addCustomEventListener("refreshFeed", (_) {
_loadPostsAgain();
});
No need to pass callbacks down a tree like it’s a family heirloom.
4. One-Time Events for Special Occasions
Like a once-in-a-lifetime deal :
addOneTimeEventListener("showConfetti", (_) {
showConfettiAnimation();
});
// Trigger it
dispatchCustomEvent(null, "showConfetti");
The listener self-destructs like a spy after its mission.
️ Under the Hood: How It Works
The event_handeler package is powered by a simple StreamController.broadcast() that acts as a global shoutbox. Your widgets subscribe to it with a type filter (like a topic), and whenever an event is dispatched, listeners for that type receive it instantly.
Here’s a peek at the simplicity:
class EventManager {
final _controller = StreamController<CustomEvent>.broadcast();
Stream<CustomEvent> get eventStream => _controller.stream;
void dispatch(CustomEvent event) => _controller.add(event);
}
That's it. No black magic. Just clean Dart streams.
Test It, Break It, Fall in Love with It
The best way to understand event_handeler is to try it once.
Open up a Flutter project, copy this into main.dart:
void main() {
runApp(MyApp());
dispatchCustomEvent("Hello World!", "appStarted");
addCustomEventListener("appStarted", (data) {
print("App says: $data");
});
}
You’ll feel the power immediately. ⚡
Ideal for Hackers, Prototypers, and UI Ninjas
- ✅ Building fast MVPs?
- ✅ Want a lightweight signal system?
- ✅ Hate bloated state management tools?
- ✅ Just need a quick way to tell another widget something?
event_handeler is your best little secret weapon.
❤️ Developers Are Saying...
“I used to cry when passing state. Now I dispatch events and laugh like a villain.”
— Anonymous Flutter Dev
“Like EventBus, but cuter, lighter, and easier to love.”
— Probably you, after trying it
Final Thoughts
There’s a time and place for complex state management. But sometimes… all you want to do is shout a message across your app and have someone hear it.
And for that?
event_handeler is exactly what you need.
Give it a try pub.dev/packages/event_handeler
Once you do, you’ll wonder how you lived without it.
why someone might choose it, when it shines, when it doesn’t, and how it can complement other systems instead of replacing them.
⚖️ event_handeler vs. Riverpod/Provider/Bloc — What’s the Difference?
| Feature | event_handeler | Riverpod/Provider/Bloc ️ |
|---|
| Mental Overhead | Super low – just dispatch/listen to events | Medium to high – requires architectural setup |
| ⚡ Speed of Setup | Instant – no boilerplate | Slower – needs state classes, providers, etc. |
| Communication Style | One-to-many event broadcasting | Direct state binding and rebuilding |
| Scope | Global (anywhere to anywhere) | Scoped (usually local to widget trees) |
| Use for UI updates? | Indirectly (trigger callbacks or methods) | Yes (triggers widget rebuilds via state) |
| ♻️ Built-in state lifecycle? | No – just messages | Yes – reactive, persistent state |
| ️ Built for reactive UIs? | No – built for communication | Yes – built for reactivity |
| Good for multi-widget sync | Yes – broadcast one event to many widgets | Needs shared state through provider |
| Complexity tolerance | Great for simple apps or isolated logic | Great for structured, large apps |
When You Should Use event_handeler
- You want to quickly pass messages across pages or components
- You don’t want to dive into full state management
- You need a simple event bus to trigger logic
- You’re building a plugin or package that needs to emit global events
- You want to decouple logic – e.g., let any part of the app respond to a payment success, logout, animation, etc.
- You want a lightweight broadcast system that’s easy to plug and play
When You Might NOT Want to Use It (Alone)
- You need tightly-coupled state with widget rebuilding (use Riverpod)
- You want fine-grained state control or persistence
- You are managing complex app logic with many dependencies
- You need devtools integration, debugging, time travel, or testability
When It Shines Best
Think of event_handeler like a pub/sub system inside your app:
- Announce something once → many parts of the app can listen.
- Very similar to
EventBus, but safer, clearer, and one-time listener support!
- It's not a replacement for state management. It's a complement.
How to Use event_handeler with Riverpod or Provider
You don’t have to choose one or the other — you can combine them:
Example: Trigger Provider Updates from Events
// event_handeler triggers an event
dispatchCustomEvent("logout", "userLogout");
// provider listens and responds
addCustomEventListener("userLogout", (_) {
ref.read(authProvider.notifier).logout();
});
Use Case: Background Events That Trigger UI Updates
Imagine a payment screen in your app that does a webview checkout. Once payment is successful, you can do:
dispatchCustomEvent("paid", "paymentDone");
Then in your main cart screen (built with Riverpod or Provider):
addCustomEventListener("paymentDone", (_) {
ref.read(cartProvider.notifier).clearCart();
});
The event triggers logic, and the state system handles UI updates. Best of both worlds!
Final Verdict: Why You Should Try event_handeler
- You don’t always need state management to get things done.
event_handeler is like the walkie-talkie that lets different parts of your app talk, without knowing each other.- It’s incredibly simple, flexible, and clean.
- And hey — you can always pair it with Riverpod or Provider when needed.
So whether you’re building a quick prototype, a plugin, or just want a leaner way to communicate across your app...
Give event_handeler a spin.
You might just fall in love with how peaceful life can be without state boilerplate chaos.