Mixins

[00:00:00]
>> So we talked a lot about components and different ways for, either rendering things, refactoring things and keeping things organized. But the biggest problem we all have run into when it comes to applications at scale is when we want to actually share functionality across the different components. And so the first technique that most people encounter in view two and this still exists in view three.

[00:00:23]
Is mixins, and so as a quick cover of what mixins are, basically we define our object API. In this case, you see that the constant my mixin has a data store that it has a reactive property of foo with the value of bar. And then what happens is you declare it inside of the component you want to use.

[00:00:47]
And so in this case we have mixins and basically, we have that erasing tasks where we're pointing it to myMixin. What this does is it'll basically, like think of it as unpackaged, the mixin inside of your script block, so that you can then get access to it. So that component on the bottom with the export default that will suddenly have, like a reactive data property called foo, that has the value bar.

[00:01:12]
And so, some people even gone even further, where you can even make mixins basically like a factory generator while you can see here that it's a function that takes in an actual variable like a parameter. And then using that it can then generate like a data source, according to where it starts.

[00:01:29]
So in this case we want to actually generate like where the current count starts from, because when we're mixing this in into different components we want to start at a different places. So this is one way that it has been done in the past. However, when it comes to mixins, there have been basically mixed reviews and overall negative when it comes to sharing functionality between components.

[00:01:47]
And the reason for this is you look back at how this works, there's nothing really stopping us from mixing in multiple mixins to actually share multiple values. In this case we know that myMixin has current count. But if we're looking at the component on the bottom, there's nothing stopping us from importing another mixin that might accidentally have the same reactive property.

[00:02:12]
And so, what you ultimately get is, you get get basically, possible property name clashes. And then when you actually see this inside of your terminal and you're getting some bug, it's gonna be extremely hard to debug because now you basically don't know where things are coming from. And so this is the opposite of the direction we want to move when it comes to building apps at scale, because Just like CSS modules, the closer we can get to pinpointing exactly where something's coming from.

[00:02:37]
And then figuring out the root cause of the problem is super critical for basically allowing us to flow forward and make progress. And so, another con as well is that we're currently only starting functionality, but In the event that people are doing like template fragments, this is another con of it, although again, less of a use case.

[00:02:59]
And so as I mentioned before, we can track where things are coming from. And so as a result, this makes it basically like, more or less inadvisable to use mixins. But of course, then you're thinking like so I should never use mixins right. That's like the easy rule of thumb.

[00:03:14]
And so like everything else in this workshop, the answer is no. Anytime anything's like you hear something that's absolute, I would say 99% of the time, there is always an exception. And so while mixins, so one of the pros, as we saw earlier is this pretty easy to use and define.

[00:03:33]
But what a lot of people miss out on the mixins is it's actually really good for refactoring a component. It's a very useful technique. So you can imagine if you have a really complex component with a large options API, like footprint and you're trying to figure out how to break it up.

[00:03:47]
It's tempting sometimes to just try to rewrite everything, but we know that that that is tricky and all the times it takes just one small misstep and all of a sudden, like the whole thing's broken, but by using mixins for a single component. Right, which sounds weird because you're like, is it mixed, supposed to be shared across components?

[00:04:03]
But if you're mixins for single components, it's a great way of kind of. Think of it like reorganizing how the options API should look inside of the component. And that might give you a better indication of what might actually be reusable functionality that can be broken out either into say like, like a utility function or a or whatnot.

[00:04:23]
And we'll talk about the composition API shortly. But this is a great way for refactoring options API components that have really, really large footprint so keep that in mind as the technique for mixins.