In the last lesson, we defined a create event on the entry editor component with define emits. This is known as a runtime declaration. While this is a powerful first step, we can enhance it further still by changing it to a type declaration. That looks something like this.
Okay, I know that this might look just a little scary. I know it did to me the first time I saw it. But let's break it down a bit. The less than and greater than symbols mean that we're using type assertion.
And the curly braces mean we're passing a type literal as the type argument. Lastly, within the literal, we're passing a call signature to define the event name called e. And then the event payload, which we can give an arbitrary name like entry. Notice how precise we can be with the payload type.
we've defined it as an object literal with a text property that's a string, and an emoji property that's an emoji or null. If we need to define more than one custom event, we could duplicate this line and adjust the event name and payload as required. However, our use case doesn't call for that, so I'll just remove that second event. If this syntax still feels intimidating, Feel free to grab the VS Code snippet that I've linked to in the description below.
It's what I used in the video. Alternately, you could copy and paste it directly from this section here in the view docs. I've left a link to that as well. Now that we've used type declaration for define events, we've got info about the payload as well as the event name.
view by listening for the create event on the entry editor. In the handler, we can now access the event with the $event keyword. And would you look at that? As soon as we type dot, text and emoji are given as autocomplete suggestions.
Perfect. This is super sweet. View now understands that the payload of the create event from the entry editor component is in object literal with these properties. This is really specific and it's really going to cut down on the errors that we might typically get when trying to communicate across components Most times event handlers aren't created in line like this, but rather have their own functions defined So let's do that instead.
I'll create a function called handle create entry and Give it an entry argument as you might expect TypeScript doesn't like that our function argument is implicitly tight as any, even though we know that this is going to be an object literal with an emoji and text property. For now, let's define it as a string. And then in the function body, I'll just console log entry so that nothing complains about unused variables. Now, if we go to use our event handler on the create event, something magical happens.
We get this red squiggly line under the create event listener that tells us that the entry argument accepted by our handle create entry function should be a string, but that the entry provided by the event is the object literal. Once again, this is pure gold. To fix it, let's make the entry argument on the handler an object literal with the proper properties and types. and VS Code actually auto-imported the type for me.
Nice. More importantly, the error on the CreateEventListener is gone. At this point, declaring types with this object literal is getting a bit verbose, redundant, and just plain messy. Therefore, this is the perfect time to create a new interface for a journal entry.
We'll do that in the next lesson.