Original subtitles

Welcome to this section, we'll be learning about the biggest change to view the latest major version

of you introduced an API called the Composition API.

Throughout most of this course, I've avoided talking about the composition API.

We haven't touched it once.

The reason is because it has a larger learning curve.

In my opinion.

It's better to learn the basics of view before jumping into the composition API.

At this point, you should be more than comfortable with writing a view application.

It's time to learn what this API is and why you would want to use it.

So what is the composition API?

The composition API is an alternative syntax for writing components.

It's purely additive.

You don't have to use it.

You can continue creating components with the syntax you're already familiar with.

The syntax we've been using is called the Options API.

As you saw, it's completely possible to build fully functioning apps with the Options API.

The composition API was introduced for a couple of reasons which we'll get into in a moment.

The composition API is not meant to replace the options API.

You can continue to write components with the options API.

If it were to be deprecated, I wouldn't have taught it to you.

I don't want you to feel like you have to learn it if you wish.

You can continue to use the options API without a problem.

Here is a comparison between the options API and the composition API.

Believe it or not, both examples do the exact same thing.

They'll generate a component with a data property called Bar.

They'll have a method called greeting that returns a string.

Despite performing the same task, they're written completely differently.

The question then becomes why should we learn the composition API?

Before I answer, I want to dispel some myths about the composition API.

You shouldn't learn it if you're hoping for a better performance or security.

The composition API doesn't offer either of these.

You'll get about the same loading times with either API.

It wasn't introduced for these reasons.

Under the hood.

Both APIs use the same functions for performing the same task.

The composition API isn't a replacement for the Options API.

In fact, you can use both APIs in the same project.

Let's get into why the composition API was introduced.

The first reason is that it offers better typescript support.

Previous versions of you have had typescript support.

Unfortunately, the implementation wasn't ideal.

There were a lot of issues with it, mainly because of the options API.

It didn't allow for some of the design patterns you can create with TypeScript.

The composition API offers better support for type scripts.

You want to use the composition API if you're going to use type scripts.

If you're not familiar with type scripts, that's perfectly fine.

The composition API can be written in plain JavaScript.

It isn't necessary to install TypeScript for writing components with the composition API.

The second reason is for a better organization.

The Options API works well for small to medium sized components.

Sometimes you'll create large components where organization may become an issue.

A component may have multiple features.

Here's an example of a component with two features.

We have a property called user and the method for retrieving the user called Get User.

There's another property called carped and a method for retrieving a product called Get Product.

It's easy to see that the user property and get user method work hand in hand.

The same can be said for the property and get product method.

As you can see visually, the logic is separated.

It doesn't seem like a big issue, but it is.

When you're working on larger components, you will have to constantly scroll up and down to work on

a single feature.

Here's the same example, but written with the composition API.

By using the composition API, you can organize code more freely.

You're not bound to defining logic in specific objects.

There's more liberty as to where you can define things.

I'll bring back the visual.

If we compare the to the composition API allows for a better organization, it helps keep you focused

on the feature you're working on.

Here's a more extreme example, this example was taken from the composition API documentation to the

left, we have the component written with the Options API.

It's highly disorganized.

To the right, we have the composition API.

It's much more cleaner and organized.

This freedom is one reason why you would want to use the composition API over the options API.

The last reason is that it offers better reusability.

This is probably the biggest reason to use the composition API.

Chances are you'll want to reuse some of the logic you've written in previous versions of View.

The only way you can reuse code was by using a feature called Mix.

Since Nixon's weren't that great, they didn't have great Intellisense support.

This meant you had to go back and forth between files to understand what was exposed to you.

There were also problems with conflicting names between mixes and components.

Lastly, there weren't better alternatives to mix since we'll be learning about mix ins in the next

lecture.

Don't worry if you're not familiar with Nixon's.

The composition API fixes these issues, you'll better understand why this is important in the next

lecture.

That about sums up why you'd want to use the composition API.

It has typescript support easier to organize code and better usability patterns.

In the next couple of lectures, we'll learn about the composition API.