Original subtitles

In this lecture, we're going to learn about mixing.

Is there a way to re-use logic within components?

Reusability can make your code more readable and manageable.

Vue offers a solution called mixes to help you with reusability.

Let's explore how to use mix ins in the resource section of this lecture, I provide a link to the mix

ins documentation page.

Here is what Vue says about them.

Mix ins are a flexible way to distribute reusable functionalities for Vue components.

A mix an object can contain any components options when a component uses a mix in all options in the

mix and will be mixed into the components own options.

If you have properties similar to one another from component to component, you can use a mix and to

prevent yourself from rewriting the same code.

It's common to have functions that you want to share amongst many components.

Mix ins are the perfect solution for this.

For this example, we're going to create a mix and that will keep track of the pages scroll offset.

We'll add the mix into a component.

In the resource section of this lecture, I provide a zip file with the starter files you'll need.

Upload it anywhere you'd like after uploading it.

Run the NPM install commands.

Lastly, start the server with the dev command.

There's nothing much to say about the starter files.

Pretty much all of them are the starter files you'll receive if you select the default preset.

I've made changes to the app component file.

Open it in your editor.

In the template, we have two elements called app and scroll position.

The app element acts as a container.

If we scroll down to the CSS, we'll see that it has relative positioning.

We're giving it an abnormally large height.

We're using a large height because we want to be able to scroll up and down the page to view the results.

The scroll position element has a fixed position.

We want to be able to see it whenever we scroll.

We want to see it because it'll contain an expression that will output the scroll offset.

You'll see what it looks like in a moment.

First, we need to create these scroll properties.

We'll be creating it in a mixing in the source directory.

Create a file called MCS in JS.

Inside the file, we'll export an object.

Nixons don't work on their own.

They're not meant to.

They are objects that will merge with an instance of view or a component.

The options we create in a mix and must match the option names in a component's options object.

If we want to create data, then we'll need to create a data function, so on and so forth.

We're going to create a data property for storing the scroll offset.

Define the data function inside the mix in.

At a property called Offset set its initial value to zero.

The offset will be zero because that's the initial value the browser will assign the offset to.

We want to be able to update the offset whenever the user scrolls on the page.

The browser emits an event we can listen to for when this occurs.

We'll start listening for the event when the component is mounted.

Define the mounted lifecycle function.

Inside the function.

We'll listen to the event by calling the Windows Add event listener function.

The name of the event is called Scroll.

If the event is emitted, we'll call the this dot update function.

This function isn't defined.

Let's define it.

Next, add the methods object to the mix in.

Define the update function.

Lastly, we'll set the offset data property to the window page Y offset property.

We have a mix and if we're keeping track of the offset of the page, will want to merge this mix in

with the app component.

This can be done by registering a mix in.

We can register a mix in locally or globally.

Let's start with a local mix in back in the app component file, we'll import the mix and file.

To register the object.

As a mixon, we need to add the Nixons property to the components configuration object.

The Nixon's property needs to be set to an array.

The arrays should be the objects that you would like merged with the component.

In our case, we want to merge the scroll mix in object.

We'll pass that in.

The properties and methods from the MCS and will be accessible via the this keyword.

We can treat them as if they were the components.

Options to begin with, we'll want to display the offset in the template.

We have a div tag with the class scroll position.

It's empty.

Let's add an expression inside it.

The expression will be set to offset.

Let's check out the application in the browser.

If I scroll up and down, the expression will be updated with the scroll offset.

Even though the code wasn't written in the component view merged the Nixon with the components options.

Nixon's allow us to re-use code by outsourcing the logic into a separate object.

We can nab this mix into any component.

There are a couple of things to be aware of when using Nixon's.

Firstly, an instance or components options will always have priority.

Let's look at an example by switching back to the editor.

Let's create a data function in the app component file.

Inside the object, we'll add a property called Offset.

Its value will be zero.

The mix already has an offset data property view will use the property in the component.

The Nixon's version of the property will not be merged with the component.

This doesn't mean the other methods we have in the mix and will not get included.

The update method will get merged with the component because the component doesn't have it defines.

Another thing worth noting is that components don't share mixing data.

For instance, if I were to register the mixing with another component, it won't share the offset data

property with the app component.

They'll be treated as independent properties in their respective components.

We don't have to worry about things leaking from one component to the next.

One component does not influence any other components data, even if they're registering the same mix

in the mix.

Since properties are duplicated, all components will have a unique version of the data.

One last thing worth noting is how lifecycle functions are treated.

If a mixing and component have the same lifecycle function defined, they'll both run.

Let's look at an example inside the app component file.

We're going to add the mounted lifecycle function.

We'll log the message that says the following app Mounted Life Cycle Function.

The Nixon is already defining the mounted life cycle function when it comes to life cycle functions.

Vue will push both methods into an array where both functions are called Let's do the browser to see

what happens.

If I scroll up and down the page, the offset will continue to get updated.

This can only happen if the mounted function from the mixing was called.

Let's open the console to see if the message is logged.

We'll find that the components mounted life cycle function was called.

If a component defines a life cycle function, it'll get called along with the Nixons life cycle function.

This gives us the opportunity to define life cycle functions without them conflicting with another freely.

Nixon's can be useful for generating generic functions that can be shared across multiple components,

while Nixon's are great.

There are a few issues with them.

Let's discuss what those issues are to discover why the development team behind Vue decided to create

the composition API.

The biggest problem with the Nixon API is name space clashing.

We have an example in our project, the offset data property in the component clashes with the Nixon.

We don't get an error from view or the editor about the problem.

We will make an assumption.

It'll assume the data property in the component should be used.

But what if we wanted to use the offset in the mix?

Well, that's not possible unless we change the names.

If we want to prevent clashing from happening, we'll have to look inside the Nixon file to discover

what property names are taken.

The Nixon doesn't directly tell us what gets added.

We have to peek inside the Nixon file to discover what gets added to the component.

This problem can be amplified if you have multiple Nixon's register to a component.

Not only will you have to check if a component has any clashing names, but you'll also need to check

with the other.

Nixon's view will not tell you if there are namespace collisions.

Nixon's can easily override one another.

It's for this reason that Nixon's are problematic.

It's challenging to develop a system that will tell you when you have name space clashing with Nixon's.

You can avoid this issue by opening the files and checking the names manually, but it's something that

can be easily overlooked during development.

The composition API is much better at handling this issue.

With that said, let's learn about the composition API.

We'll look at how this issue is resolved in the next set of lectures.