Episode 6: Let's Look at the Type of createApp • frontendBaby

The Tale of a Young Raccoon Dog Whose Life Was Drastically Changed When He Barged into the Forest Doctor’s Laboratory Because He Just Couldn’t Understand Vue.js

Note

This story was written with the help of generative AI, aiming to make learning frontend technology enjoyable. While we have taken the utmost care to ensure the accuracy of technical information, we cannot guarantee that all content is completely true. Please enjoy this as a supplementary learning tool and with a relaxed mindset.

Character Introduction

Dr. Frontend: A knowledgeable doctor who lives in a laboratory deep in the forest and knows everything about frontend development. He always kindly (and humorously) answers Ponkichi’s simple questions.
Ponkichi: A curious young raccoon dog. His dream is to become a frontend engineer. He recently started learning Vue.js and is very intrigued by its depth. He has a special skill of exclaiming “Pon!” and jumping up when he learns something new.

Episode 6 🦝 “Let’s Look at the Type of createApp”

Having acquired a new magic map called TypeScript, Ponkichi knocked on the laboratory door, thrilled about what discoveries awaited him today.

Ponkichi: “Hello, Doctor! TypeScript is so much fun! Pon!”

Dr. Frontend: “Oh, Ponkichi. I like your enthusiasm. Today, let’s take a look together at what our usual createApp function looks like in the world of TypeScript.”

The Doctor displayed something called a “type definition file” from within the Vue.js library on the monitor.

Ponkichi: “A type definition file…?”

Dr. Frontend: “Yes. It’s a file for TypeScript that serves as a blueprint, containing information that says, ‘The functions and objects in this library have these specific shapes (types).’”

What was written there was the form of createApp, written with unfamiliar symbols.

export declare function createApp<HostElement = Element>(
  rootComponent: Component,
  rootProps?: Data | null
): App<HostElement>

Ponkichi: “Whoa…! Is this createApp!? It looks like a magic spell…”

Dr. Frontend: “Hahaha. I admit, it can be a bit startling at first glance. But if we look at it one piece at a time, it’s not difficult at all.”

The Doctor pointed to a part of the code.

Dr. Frontend: “First, you can see it says function createApp(...), so you know it’s a function, right?”

Ponkichi: “Yes! I get that part!”

Dr. Frontend: “Next, let’s look inside the (...), at the arguments. It says rootComponent: Component.”

Ponkichi: “It has a : (colon)…! This is just like a: number from yesterday! So, the type of the rootComponent argument is Component!”

Dr. Frontend: “Exactly! Wonderful, Ponkichi! The object we always pass as the first argument to createApp is treated as the Component type in the world of Vue.”

Ponkichi: “I see! Then what about the rootProps?: Data | null next to it…?”

Dr. Frontend: “The ? is a marker that means, ‘This argument is optional.’ And the | means ‘or.’ So, the rootProps argument can be of type Data, or null, or it can be omitted entirely.”

Ponkichi: “I see, I see. So arguments have various rules, too.”

Dr. Frontend: “And now for the most interesting part.”

The Doctor pointed to the <HostElement = Element> and the return value, : App<HostElement>.

Dr. Frontend: “This <...> symbol is called a ‘Generic.’ It’s an incredibly powerful piece of TypeScript magic that allows you to pass types around like arguments.”

Ponkichi: “Generics…? Passing types as arguments…?”

Dr. Frontend: “For now, it’s enough to think of it as ‘a mechanism for creating flexible types that can handle various other types.’ For example, App<HostElement> means it returns a type called App whose contents change slightly depending on the HostElement type.”

Ponkichi was a little confused, but he was deeply impressed that the familiar createApp function was built upon a solid blueprint with strict rules (types) for its arguments and return value in the world of TypeScript.

Ponkichi: “Amazing…! The createApp I’ve been using without a second thought was protected by such solid types! That’s why TypeScript gets angry when I try to use it incorrectly!”

Dr. Frontend: “That’s right! Thanks to this type definition, we can use createApp safely and correctly.”

Ponkichi: “Doctor, I want to know more! What shape does this Component type have?”

Ponkichi’s spirit of inquiry was burning brighter than ever.

Dr. Frontend: “Hmm! An excellent question. Then next time, let’s try to unravel the secrets of that Component type.”

Ponkichi: “Yes! I can’t wait! Pon!”

🌟 Today’s Takeaways

In the world of TypeScript, the shapes of library functions and objects are written in type definition files.
createApp also has strict types for its arguments and return value.
The : (colon) is used to specify an argument’s type, like rootComponent: Component.
? means “optional,” and | means “or.”
<...> (Generics) are a powerful mechanism for making types more flexible.

Next Episode Preview: “What is the Component Type?”

The familiar component object we pass to createApp. What is the structure of its true identity, the Component type? Let’s peek inside with Ponkichi!

👨‍🏫 Doctor’s Note

In today’s lesson, we ventured deep into the node_modules forest to peek at Vue’s type definition file (.d.ts file).

Did you notice that what was written in there wasn’t just a plain text file, Ponkichi? That’s called a “type definition file,” and it’s like a “blueprint” or a “map” that teaches TypeScript, “This function takes these kinds of arguments and returns this kind of value.”

Thanks to this file, our code editor can provide smart autocompletion and prevent mistakes before they happen.

And now, for a very important promise. The node_modules forest is a sacred ground managed by package managers (like npm, yarn, or bun). While we may peek inside to learn, you must never, ever edit the files inside directly.

You might rightly wonder, “Is it just because my changes will be overwritten the next time I install packages?” That is one reason, but there are more important ones.

The biggest reason is that it breaks reproducibility. If you change a file only on your computer, you create a special environment that is different from your colleagues’ computers or the server that builds the application for production. This leads to the very tricky “it works on my machine” problem.

Furthermore, node_modules is not tracked by Git, so any changes you make won’t be recorded in the version history or shared with anyone else. It becomes a “quick fix” that is bound to cause trouble later.

Therefore, remember to treat node_modules not as ‘source code’ that you edit, but as a ‘read-only library.’ For now, it’s enough to just know that such a thing exists. Someday, when you’re ready to create your own library, you will truly appreciate the value of these type definition files.

End of Episode 6