Thread by @davidfowl

Lets talk about events. We want to write some code that reacts when something happens. This pattern exists in many domains from UI programming to IoT to serverless. What do the programming patterns for this look like today in #dotnet and #csharp?

We create a button (imagine this was referenced by a form or some UI component), then hook up an event handler and write to the console when a button click event happens. This is the one of the most popular and idiomatic event handling paradigms in .NET today.

It's existed for years and years in many different programming languages and domains. There may or may not be data associated with these events.

What APIs can you use to represent an event? Lets take a look. First the O.G. EventHandler. Built in to .NET since 1.0, probably inspired by VB 6 (I'm sure somebody will fact check me on this). Many of the existing APIs in use these.

The big downside with exposing events like this are NO async :(. There's no async event handler type so its impossible for callers to know when the callback is actually done. Many UI stacks in .NET use async void event handlers and custom synchronization contexts to manage this.

Then came IObservable<T> which was born in .NET by @headinthebox but it's more popular in Java than it is in .NET. Reactive programming is an alternative programming model for events where you treat events from the same source as a single stream.

Button click looks like this with Rx. Clicks is a stream of click events. Where this really shines is when you use the Rx operators/combinators, they make complex tasks easy to implement (ever had to implement debouncing manually??)

This is a paradigm shift. reactiveui.net is an entire library built around these patterns and it shows what the mental shift looks like going from event handling on UI elements to streams of values.

There are a ton of other ways to represent evented APIs, for example the new minimal APIs in .NET 6. This pattern is passing a delegate to a method overload (MapGet in this case).

One benefit over the EventHandler property approach is that it can support overloads and callback shapes. Want to support both sync and async delegates? You can add overloads to do so (more parameters? multiple generic arguments etc). Methods are more powerful for API evolution.

Other APIs in the BCL also just take a straight up calback (like timers). This API also overlaps callbacks and doesn't do back pressure, that's for you to manage.

The above models are all callback based. You pass some information about which event you want to subscribe to, and you pass a function that will be called back in the future. You do not control how data is pulled out of this event stream (there's no concept of a stream exposed)

IAsyncEnumerable<T> (originally came from Rx) but was recently added to the .NET 6 and to the C# 10. It's the only option that gives the user access to an event stream in a way where they control how often events are pulled from the queue.

It also side steps the sync/async problem since the user is the one that is in control of consumption (well I guess it means you're always async because events are async :)).

Going back to our button click example, this is what it looks like with async enumerable. I'm not sure if we'll see this pattern emerge to replace events and I'm not sure that it's easier but it does solve certain class of problem with events.

The one awkward thing so I've found with this so far is that concurrent events need to be fired up on different tasks. Which one of the below do prefer?

I expect the left because it’s how we’ve been trained to handle events from the get go

I want you to go look at all of your callback based code and see if pull based vs pushed based is a better approach.