Why Separating Analytics Logging from Business Logic is a Game-Changer

Learn how to avoid mixing your analytics event with actual event handling in Bloc.

Feb 06, 2025

Hey there, fellow developers! 👋

Today, I want to talk about something that might seem small but can have a big impact on your codebase: analytics logging. Specifically, why it’s a good idea to keep your analytics logging separate from your main business logic. I’ll walk you through why this approach is cleaner, more efficient, and just plain better. Let’s dive in!

The Problem: Mixing Analytics with Business Logic

Imagine this: You’re working on a feature, say, a player list in a sports app. Every time a user taps on a player or applies a filter, you need to log an analytics event. The straightforward approach might be to log the event right inside the function that handles the tap or filter action. Something like this:

At first glance, this seems fine. But let’s think about it:

It mixes concerns: Your function is now doing two things—logging analytics and handling the tap action. This violates the Single Responsibility Principle.
It can block execution: If the analytics logging is awaited, it might delay the main action, especially if the network is slow or Firebase is having a bad day.
It clutters your code: Over time, your business logic gets buried under a pile of analytics calls, making it harder to read and maintain.

The Solution: Separate Analytics Logging

Now, let’s look at a better approach. Instead of mixing analytics logging with your business logic, you can handle it separately. Here’s how I did it in my PlayerListBloc:

In this setup, the onEvent method handles all the analytics logging, while the actual event handling is done in separate functions like _playerTap and _filter. This separation of concerns makes the code cleaner and easier to maintain.

Why This Approach Rocks 🚀

Cleaner Code: By separating analytics logging from business logic, your code becomes more readable and maintainable. Each function has a single responsibility, making it easier to understand and modify.
Non-Blocking Execution: Notice how I used unawaited in the LogEventUseCase? (More on this in next section). This ensures that the analytics logging doesn’t block the main execution. The app remains responsive, and the user experience isn’t affected by slow analytics calls.
Centralized Analytics Handling: With the onEvent method, all your analytics logging is in one place. This makes it easier to manage and update your analytics logic without touching the core business logic.
Scalability: As your app grows, you’ll likely add more events and analytics. This approach scales beautifully because you can add new events without cluttering your business logic.

Well, all this is okay, but you must be having these questions.

Which one of these two methods gets called first - onEvent or on?
Do they run in parallel or one after another.
Why using unawaited ?

The Key Differences Between `on<Event>` and `onEvent`

Execution Order: Which is Called First? Do They Run in Parallel or Sequentially?

When an event is added to the BLoC (e.g., via add(PlayerTap())), here’s what happens under the hood:

As soon as the event is added, the onEvent method is invoked.

Sequential Execution: onEvent and on<Event> run one after the other, not in parallel.

onEvent is called first, and once it completes, the on<Event> handler is invoked.
This ensures that side effects (like logging) happen before the business logic is executed.

Why Not Parallel?

Running them in parallel could lead to race conditions or inconsistencies. For example, if onEvent logs an event but the on<Event> handler fails to process the event, your logs would be inaccurate.
Sequential execution ensures a predictable and controlled flow.

A Friendly Reminder: Don’t Await Analytics!

One last thing—avoid awaiting your analytics calls unless absolutely necessary. Analytics logging is important, but it shouldn’t come at the cost of user experience. By using unawaited, you ensure that your app remains snappy and responsive, even if the analytics service is slow.

Wrapping Up

So, there you have it! Separating analytics logging from your business logic is a small change that can make a big difference. It keeps your code clean, ensures non-blocking execution, and makes your app more maintainable and scalable.

Next time you’re tempted to throw an analytics call into the middle of your business logic, take a step back and consider this approach. Your future self (and your teammates) will thank you!

Happy coding! 🎉

What do you think? Have you tried this approach in your projects? Let me know in the comments below! 👇