When you think about unions and intersections within TypeScript, it maps quite nicely to bend diagrams from set and they can be used to highlight an issue that you might have within your mental model for these particular types. So let's take a look. Consider two simple types, one with the property name of type string and one with the property age of type number. Now we can combine them in two ways. We can combine them into a union or we can combine them into an intersection. Now with the union, what we are trying to say is that the object will contain the properties of the name or it'll contain the properties of age.

And with an intersection we are saying that it must contain the properties of name as well as age. Now let's create some simple objects, name, age, as well as name and age to demonstrate the behaviors of these combination types. Now for the union, as you would expect, we can assign the name, object or the age object, but what you might not have expected is that we can also assign it the name and age object. The reason why this works of course, is because of the structural nature of TypeScript. That is an object containing name and age is also an object that contains the property name and it is therefore structurally compatible with this union.

And the intersection type on the other hand, is something that only accepts an object that contains both name as well as age. So if we try to assign it just the name or just the age, we will get a compiled time error. Now let's take a quick look at this from a set theory perspective, we have objects that have name, we have objects that have age, and then we have objects that have both name as well as age. And as we have seen as far as unions are concerned, all of these objects are perfectly valid. Whereas for an intersection, an object must support both of these properties and we only get a subset of the objects that might contain name or might contain age.

Now, even though that is a great mental model to have it is not entirely accurate. Let's reconsider this union of name or age. As we have seen, we can assign it objects that contain name or age or objects that contain name and age. However, this last case is actually just a lucky coincidence because of Typescripts structural typing. And this union is not designed to support this use case. We can demonstrate that when we try to filter out which particular member of the union and object currently belongs to, we accept the union and we check if it has the name property

and it'll filter it out to the name object. And we will be able to read the name property of type string. And if we check if it has an age property, we will successfully be able to filter out that ages of type number. However, if we check if it has both name as well as age, which is a valid object that we did assign, TypeScript will complain because as we have been saying, the union is designed to say that the object can be name or age. The case where we can assign an object containing both the properties is an unlucky side effect of Typescripts structural typing.

So if this is the mental model of for union types that you have, it's probably incorrect. It is more along the lines of this. Here we are saying that the object can either be named Or it can be age. And just coincidentally, an optic that contains both name and age is something that can be assigned to these, but we won't be able to read them safely with this mental model in place. Here's a thought experiment for you. How can you make the union fully support the use case where you do provide both the values? In other words, we don't want to see an error over here because clearly it is a valid object and I've intentionally sort

of given away the answer over here. If you want the union to support name and age, then we can add that to the union. And with this added, the error goes away because here's what the union looks like within Typescripts brain.