Let's take a look at how we can prevent any Naimi collisions between an import statement from react
and react Dom that is written out by user and import statements written out by you and I that are hard
coded into our users code.
OK, so to solve this, we're going to use a little bit of a trick.
Let me first give you a very quick reminder about jazz in general.
Remember, whenever you write out a jazz element like this right here, whenever it gets transpired,
it is going to be turned into a function call to react, create element.
So in this case, the one element that you see right here would be turned into something like react,
create element, each one.
And then some other arguments will be provided to it as well.
Yes, build, which is what is transpiring, our code is making a very big assumption here it is assuming
that if you and I ever write out some basics, we want to turn that into a function call specifically
to react, create element.
But that setting can actually be customized.
We can tell.
Yes, build that.
Instead of making a function called to react, create element, we can instead have it put in there
something like a function called to make jousts, or it can be to J Builder or whatever else.
We can change that reactive element into any little snippet of text we want and we're going to make
use of that feature to avoid this naming conflict.
So here's what we are going to do back inside of our code editor.
We're going to find our hardcoded in Port Stephens for react and react, Dom, rather than importing.
Just react and react.
Dom, I'm going to change this to underscore, react and underscore.
React, Dom.
I'll then go down to where we make use of them right here, and I'm going to replace that with underscore
react Dom.
And then finally, we're going to change a little setting inside of itself.
We're going to say that whenever it sees a sex element, rather than replacing with reactive element,
we want to replace it with underscore, react, create element.
So we're simply renaming our imports and then telling everything on the side or everything inside of
us build to just reference, underscore, react instead.
So this will allow a user to very easily import, react or react if they want to.
They can do whatever they want to with it, no problem whatsoever.
But if they're going to make use of our show function, then behind the scenes it'll be making use of
this underscore, react and underscore.
React, Dom.
So let's now go back over to our ESKILD configuration, and as I mentioned, we're going to change one
or two settings in there to say whenever it sees jousts, turn it into underscore, react, create elements.
So I'm going to find our bundler directory inside, there is our index file.
So here's our bundle function, we will scroll down to where we set up our building service.
And then to our configuration object, we're going to add in two little settings, we're going to add
in Sex Factory is underscore, react, create element.
And fragment is underscore, react, fragment.
Ex fragment is being placed inside of here just in case we ever write out a fragment which remembers
kind of like an empty set of brackets.
OK, so let's now save this Belbek over.
I'm going to refresh.
And now I should still be able to do a show.
With an H1 and put in some text inside their.
That works out just fine, and I should also be able to do an import for react from react, and I no
longer get any kind of naming collision.
So this definitely works out just fine.
Now, the one thing you might be a little bit concerned about the solution, does this mean that we
are bundling up react twice behind the scenes?
Are we including two separate copies of REACT?
Well, no, we are not.
Yes, Bill is very intelligent.
It will recognize that we are importing react twice into our project.
It's only going to include the source code for yakked one time.
And then internally it will create two separate variables.
One variable will be called react, the other will be underscore react.
Those will both be references to the same copy of the REACT Library.
So let's say that this is a pretty reasonable solution.
A user can also still import to react, Dom, if they want to.
And no issue with that either as well.
OK, so I'd say this looks like a pretty reasonable solution.
Let's take a pause right here and continue on in just a moment.