Provide & Inject

[00:00:00]
>> The other one that some of you may have heard about, but it's a little bit rare is the Provide/Inject API. And so the way this works is inside of our component, you can actually call this provide function that basically think of it really like a data store.

[00:00:17]
In that you are providing this object that provides properties to this child component that will eventually receive the data. And so you might be thinking well, how is this different from props? The thing about provide inject is that with props, we have to focus on parent child relationship, right.

[00:00:36]
So, the moment you have a great grandchild what you'll find is you'll have to if you did the prop solution, you'd have to do the prop strain basically. Parent will have to pass it to the child, which will pass it to the great grandchild will then pass it to the great grandchild.

[00:00:50]
And that's not a great way to mitigate code, right, because now you basically created this dependency and it's just not the best solution. So provide inject on the other hand, well basically says, regardless of where you are inside of the child component tree inject these things. So you'll see here that inside of this child component that's receiving all these properties it takes and you basically define an inject property.

[00:01:16]
And then you define what you're going to receive. And so this is pretty cool because what this allows you to do is theoretically, you can have this great, great, great, great grandparent component that might define like certain prop options or whatnot. And so as you can see in this example, right, typically this component has a prop of option key.

[00:01:33]
But the default value we can actually have that be injected from whatever great grandparent that we care about. And so when you think of that, you're probably thinking like, wow, this is pretty cool. Like this allow me to just shoot data all over my application. So it's true that as far as it's pretty easy to share, data and methods with descendants, and it skips over that prop strain.

[00:01:56]
And more importantly, we can see that like components, unlike the mixins example, components can actually choose what they want to receive. So as we saw that mixins earlier will just accept whatever is provided to them. And so while this is really cool, the problem is that there are definitely cons to this.

[00:02:15]
And why it's not seen as pervasively through production apps. And that's because like in Vue 2, for example, there are certain reactivity caveats when it comes to what is reactive and what isn't. And so this makes it fairly complex to utilize in a Vue 2 app successfully. There are helper libraries to help make sure that everything's reactive.

[00:02:32]
I recommend doing your own research on that, cuz again that can be a whole topic in and of itself. In Vue 3 some of the reactivity caveats have been solved. But again this just makes for just an additional learning curve for how it works. But within architecturally speaking, what this does is this creates a tight relationship now between these two components.

[00:02:51]
That is honestly not immediately a parent. In the slides I showed you right. If we go back, if you're looking at this component, you actually really have no idea where this is coming from. And so if you start utilizing this technique too much or you've rely on it, you'll find yourself just randomly, you'll have a series of injected keys.

[00:03:10]
Like values without really any sense of where it's coming from. And so then you're relying on the developer to sort of be consistent with how you named properties. Which isn't really resilient, right. Especially on an application that scales. And so you end up suffering from a lot of what mixin suffer from as far as it's hard to figure out where things are coming from.

[00:03:35]
And there's not but you've also inadvertently created this tight relationship because if you're relying on this injected value. The moment this component is taken out of context, it's gonna break, because it has some dependency. And so, as far as using provide inject if you do feel like there is a good basically [COUGH].

[00:03:56]
If there's a good use case for provide inject, following the naming convention we talked about earlier where you're tightly coupling the naming. So again todo lists todo this item. Imagine if todo list is providing something that we want to inject into a component inside of the todo component folder.

[00:04:13]
Then you should make sure that it's prepended with that accordingly so that if in todo list item name, there's an injection there. That at the bare minimum there is that hierarchy and relationship between the two so that at least it's somewhat communicated. So that's something to consider when it comes to using provide inject.

[00:04:33]
And so as just another reminder is that provide an inject it's really primarily for advanced plug-in component library usage. And so generally, like I said there are probably better techniques than provide inject to actually share functionality across your application. But I know that when people get to enterprise level apps that oftentimes they'll look for, these little techniques.

[00:04:58]
And so this is why I thought it was important to share with you the pros and cons with it so that you can do with it, what you will. But I would say that generally speaking, if you're reaching for provide inject. Then there's a really good chance that there probably is a better way of doing what you wanna do.

[00:05:12]
Whether it's through view acts like state management, or there's probably a better standard that sort of removes a lot of the caveats that come with provide inject.