All language subtitles for 010 Advantages of the Composition API_en

In this lecture, we're going to learn about the advantages of the Composition API.

We've become familiar with the API in these past few lectures.

You have all the knowledge you need to start using it.

I want to discuss one of the main advantages of using the composition API.

We'll see how it matches up against Nixons.

In the very first lecture, I briefly went over the reasons why you'd want to use the composition API.

Firstly, it has better TypeScript support.

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

As you saw in the past few lectures, it isn't necessary to use TypeScript with the composition API.

Secondly, it allows for a better organization.

We saw firsthand how that works.

We were able to define variables and functions in any order we like.

Unlike the Options API, we weren't bound to defining everything in specific locations.

If we want, we can move everything to random places in the setup function, the component will still

work.

Thirdly, it makes reusability easier.

It opens up an interesting pattern where we're using code that's better than using mix ins.

In this lecture, we're going to specifically look at how we can create reusable code.

Before we dive into some code, there's a concept I want to discuss called a composition function.

The definition of the word composition is the action of putting things together.

In that regard, a composition function is a function made up of other functions.

It's common practice to want to combine things together for reusability reasons.

If you have common logic among components, you will most likely outsource the code in a separate file,

import it and then load it into the component.

Currently I'm working on the mix INS project we worked on in Lecture two of this section.

Towards the end of the lecture, I showed you one of the biggest problems with Nixons.

In the data object, we have a property called Offset.

If we were to look at the mix and file, we'd see that it also has a data property called Offset.

Despite that, switching back to the component, we aren't receiving errors.

We won't get errors in the browser nor in the editor.

We aren't aware of the problem this will cause because the environment we're working in won't throw

an error.

This will mean we'll have to investigate by looking around our code and files to find the issue.

For something small like this, it won't take long to find the culprit of the issue.

However, in larger projects, this can quickly become a nightmare.

We can't even rename the properties in the component.

If we found a conflicting name, we would have to open the mix and file and rename the property from

there.

Then we would have to go to every component that uses the mix and to reflect the change.

It's not an efficient way to go about things.

There are workaround patterns available such as high order components.

The View team has decided to provide a solution that's much easier to work with.

The composition API is the solution they came up with.

Let's go back to the composition API project we were working on.

The setup function has become quite large.

It's starting to become unreadable.

Let's split the function into multiple functions.

There are two things we'll put into separate functions the code for the number, example and phrases.

Example, we'll create a directory for holding our code in the source directory.

Create a folder called Hooks.

The name Hooks is a common naming convention for composition function files inside the newly created

directory.

Create a file called Number JS.

We're going to export a function called use number.

Next back in the app component will cut the num variable increment function and double computed property.

I will paste this into the number function we exported in the number JS file.

The ref and computed functions will need to be imported from the view package.

We'll do that at the top.

We'll return the num increment and double values in an object.

We've successfully created our first composition function, just like mix ins by themselves.

Composition functions aren't meant to be used alone.

They're meant to be merged with a component.

We gave our composition function a unique name by adding the word used before the name.

It's not required to do this.

It's common practice to prefix functions with the word use.

It helps developers identify if the function is a composition function.

It's a function meant to be merged with a component.

The naming convention is inspired by React.

If you worked with React, you're probably familiar with this naming convention.

It's a great way to help developers to identify composition functions.

We'll be following this practice.

Let's merge it with the component back in the app component file.

We'll import the use number function from the number file.

Then right before the return statement we'll create a variable that de structures the object returned

by the user number of function.

In relation to reusability.

Here's one advantage the composition API has over MCS.

Since we don't have to retrieve every property and method from the composition function, we have the

option of selecting what we want to grab from the function.

When we're working with, Nixon's view will merge the entire mix in object with the component.

We don't have a say in the matter.

By using the composition API, we'll have an idea of what we can retrieve because of IntelliSense and

tell us.

Sense is a feature in Visual Studio code.

You may have an editor that has something similar.

It's the ability to perform code completion.

The editor is able to detect what the function is returning.

It'll output a list of possible values.

This feature helps us greatly because we won't have to switch back to the file to check what's being

returned.

This feature isn't available with Nixon's.

We're going to grab the NUM increments and composition properties.

We won't need to update the return statement because the values are using the same names.

We're finished with creating our first composition function.

Let's work on creating another.

We have two variables for containing the phrase We'll move these into a composition function.

The watcher will be moved to create a file called phrase JS inside the Hooks Directory.

We'll return a function called use phrase.

Switch back to the app component file, we'll cut the phrase variable, reversed phrase variable and

watch function paste them into the use phrase function.

We'll add a return statement to return the phrase and reversed phrase variables in an object.

At the top of the file.

We'll import the ref and watch function from the view package.

The composition function is ready back and the component will import the use phrase function from the

phrase file.

While we're here, we can update the import statement from the view package to remove the computed and

watch functions.

We don't need them anymore.

Back down in the setup function, we'll create a variable that de structures the object returned by

the use phrase function.

We'll want to grab the phrase and reversed phrase properties.

We don't need to update the return statement in the setup function because the names are the same.

Let's give things a test in the browser.

Refresh the page.

If we press the increment button, the numbers will continue to work.

The form for inputting a phrase works to we'll even get the phrase reversed.

Fantastic.

We've created two composition functions.

They're highly reusable.

We can use them in any component without experiencing the same issues we had before.

We can even rename the variables.

This flexibility isn't something we were able to do with Nixons.

Let me show you what I mean.

Back in the editor, we're going to modify the phrase file.

We'll create another reactive reference.

It'll be called NUM.

Its value will be an empty string.

We'll add it to the return statement.

Back in the component file, we'll add it to the list of properties to extract from the object.

Our editor will throw an error.

It's saying that we already have an identifier called NUM.

The number composition function is already returning a variable with the same name.

We have two identifiers with the same name.

Previously view would use whatever mix and it wanted.

If there were conflicting names, it didn't throw an error at us.

Things are different with the composition API.

At the end of the day, we're writing JavaScript functions.

This will not slide with JavaScript.

It does not like it when there are conflicting names.

Luckily, we can resolve this issue by renaming the variables in the component.

We don't have to rename them in the composition functions we created.

JavaScript allows us to rename properties we'd structure.

We'll assign the NUM property, the name of phrase num.

Next, we'll add it to the list of values to return.

This reassignment will fix the issues we had.

We can continue to use properties and methods with the same names across multiple composition functions.

We'll know when there's an error because our editors will let us know when names clash.

It's not like last time with Nixons where everything was up in the air.

In terms of reusability, the composition API is far superior.

This is one of the reasons why you may want to opt to use the composition API over the options API.

It allows us to compose a component with little to no hassle.

That wraps it up for the composition API.

It's a very powerful API for composing a component.

I want to repeat myself again.

The composition API is not a replacement for the options API.

The primary purpose of the composition API is to help with reusability.

If you find yourself in a situation where you need to reuse logic, the composition API may be what

you're looking for.

Otherwise the options API will suffice.

We'll continue our discussion of the composition API in the next lecture.