has an event type, which is the union of userCreated or userDeleted. So these are the two event types we have here and here. And then it has this parameters, this parameter bag called parameters and it'll list an id, which is common in both. And then it will put the name and email as optional parameters because they only exist in one event type. And they'll often extend this out to much larger interfaces and event types where they might have dozens of parameters and various things, maybe five or six different event types in the union. And they'll create an event type that looks like this. And the issue with creating an interface to combine or encapsulate these types like this is it becomes very hard to discriminate on the different event types. So what do I mean by that? So imagine we had a handleUserEvent that takes an event, which is a UserEvent. And a UserEvent is this interface we just created, which unions the userCreated and userDeleted like this. Let's say we wanted to have a handler. We wanted to do a specific action on a userCreated.

event. And a UserEvent is this interface we just created, which unions the UserCreated and UserDeleted like this. Let's say we wanted to have a handler. We wanted to do a specific action on a UserCreated event. So we check the event type and we say, if it's a UserCreated event, go do something with the UserCreated event. In this case, we're just going to console.log out the name and we're going to return. And then if we have an event type for UserDeleted, we want to go do something with that. Here, we're just going to log out the ID and return. Now, this might look perfectly acceptable, perfectly fine. You might not see any obvious issues with this. But if I were to also do something like log out the name of the user in the UserDeleted event, we get no type errors here. And if we scroll back up to our UserDeleted event, we have no name on the parameters. And the reason this isn't throwing a type error is because in our combined event, we've made the name an optional parameter. So it could exist or it could be undefined.

event, we have no name on the parameters. And the reason this isn't throwing a type error is because in our combined event, we've made the name an optional parameter. So it could exist or it could be undefined. So in this case here, console.log is still going to work because it's just going to log undefined. That's not a runtime error that is still logging a value. So we're not going to get any type errors here. But you can imagine if instead of logging this to the console, we were actually expecting to do something with this name. Maybe we would concatenate it in a string or set it as the subject of an email or use this data or even just something as trivial as toUpperCase. Now, we're going to get a type error saying the object is possibly undefined. But we know it's not possibly undefined. We know that name is never actually going to exist on a UserDeletedEvent. So what we have here is a structure for our type or our interface that appears to do the job, but it doesn't actually enforce the strictness of our domain.

event. So what we have here is a structure for our type or our interface that appears to do the job, but it doesn't actually enforce the strictness of our domain. We know that we can't ever have a name on a UserDeleted event. And yet TypeScript is saying we could possibly have an undefined one or even a defined one. So this is not how you would go about unioning these two events. But I often see people try and do this and it leads to some very weird cases where they get some unexpected runtime behavior and they wonder why TypeScript isn't helping them prevent that behavior. So the way you actually want to type this is you want to create two distinct types. We want a UserCreated event, which has the event type of userCreated and the parameters for that event. We create a UserDeleted event, which has the event type of userDeleted and the parameters for that event. And then we create a new type, which we would call UserEvent, but I've called BetterUserEvent here to avoid naming collision. And we would union these two interfaces.