Flutter developers, unite!
If you've ever gotten frustrated with setting up full-blown state management just to send a simple message across your app — maybe from a payment success page back to your home screen — you're not alone.
Enter: event_handeler
, a lightweight, fun-to-use event broadcasting system that makes your app feel more like a party and less like a board meeting. 🎉
Let's dive into why this little package is a hidden gem, how it can complement your existing setup (like Riverpod, Provider, or Bloc), and why you should definitely give it a try.
🎩 What is event_handeler
?
It’s a Dart package that lets you:
- Send custom events from anywhere in your app
- Listen to those events anywhere else
- Dispatch global messages, no context required
- Handle one-time events automatically
Imagine it as your app’s internal radio station. Tune in to a channel (event type), and whenever someone broadcasts a message, you hear it loud and clear.
✨ Use Cases That Just Make Sense
1. 🚀 Triggering Actions from Background Pages
Your payment page finishes a transaction:
dispatchCustomEvent("done", "paymentComplete");
Back on your cart screen, you’re listening:
addCustomEventListener("paymentComplete", (_) => showSuccessToast());
Boom. Simple. Fast. No weird state gymnastics.
2. 🔄 Coordinating Across Screens
User logs in? Let the profile and home screens update in harmony:
dispatchCustomEvent(userData, "userLoggedIn");
Anywhere in the app:
addCustomEventListener("userLoggedIn", (data) {
updateProfile(data);
showWelcomeToast(data.name);
});
3. 🧪 Handling Events Once (and Only Once)
addOneTimeEventListener("userDeleted", (_) {
Navigator.pushReplacementNamed(context, '/goodbye');
});
Perfect for alerts, confirmations, and transitions that should only happen once.
⚔️ event_handeler
vs State Management Libraries
Let’s line it up against the big dogs like Riverpod and Bloc:
Feature | event_handeler |
Riverpod/Provider/Bloc |
---|---|---|
Setup time | Super quick | Requires architecture |
Rebuild widgets | Manual | Yes |
Broadcast style | Global (decoupled) | Scoped (contextual) |
Best use | Message passing | Reactive state updates |
Boilerplate | Almost none | Some required |
Widget-dependent? | Nope | Yes (usually) |
💡 When to Use It (and When Not To)
✅ Use It When:
- You want to keep things simple
- You just need to send events around
- You’re working on a plugin or tool package
- You don’t want to rebuild widgets
- You’re building non-UI logic that needs communication
🚫 Don’t Use It Alone If:
- You need a persistent or reactive state
- Your UI rebuilds are tied to state changes
- You want devtools/time travel/debugging integrations
🔄 Using It With Riverpod or Provider
Don't choose — combine!
// event triggered by event_handeler
dispatchCustomEvent("logout", "userLogout");
// update Riverpod state
addCustomEventListener("userLogout", (_) {
ref.read(authProvider.notifier).logout();
});
Use event_handeler
For fire-and-forget comms, and use Riverpod to handle the reactive state part.
🧘♂️ Developer-Friendly Philosophy
- Minimalism-first: Why over-engineer something simple?
- Works everywhere: Widgets, services, controllers, doesn’t matter
- No build context madness
- Feels like Dart, not magic incantations
🧪 Try It, Just Once
"Try
event_handeler
once, and you may never go back to callback spaghetti again."
Whether you're an indie dev, a pro working on a plugin, or just someone tired of shouting across widget trees — this is your sign to give it a go.
Check it out on pub.dev, toss it into your project, and let your app's parts start talking like besties at brunch.
👇 Final Thoughts
event_handeler
is not trying to replace Riverpod. It's not trying to outsmart Bloc. It’s here to simplify the moments in your app where traditional state management feels like overkill.
In short: it's your app's walkie-talkie. Keep it handy.
📡 Happy dispatching!