All right, my friends, we've got this kind of happy middle ground, it is not perfect, but it's pretty
good for actually running users code.
So you might notice that now I'm seeing right here inside this diagram that at some point in time we
need to fetch an HTML document.
So how are we going to somehow get an e-mail document into that iframe?
Well, we could definitely just make a request directly to local three thousand and get that tested
HTML document, which we already have put together.
That's technically what we're already doing.
But remember, this introduces an extra request that we have to make every single time a user changes
some code so that it always just means we're going to take some extra little number of milliseconds
to run users code.
User is on a very slow device and we are eventually running this application and kind of like some cloud
environment or this is a publicly hosted version of our app.
This extra request is just extra time that it's going to take to run a user's code.
I'm kind of curious, is there a way that we can get away with not having to make an extra request to
get that HTML document, but still load up some content inside of an iFrame?
Yes, there is yet again some extra little knowledge around eye frames.
Let's go back over to our code editor.
I want to show you another feature around them.
So at this point time, we've really just been talking about creating an iFrame, putting an SRT attribute
inside there and the iFrame, whenever it loads up, is going to make a request to that URL and then
try to get some HTML and display it.
But there's another way that we can load up content directly into an iFrame without making any request
at all.
I'm going to remove that Sarsae property then underneath my component right now.
Eventually we're going to put this code in a way better place, but just a very quick demonstration.
I'm going to declare a variable heat down here called TML, I'm going to make it a multiline string,
so make sure you've got some back ticks inside their.
Then I'm going to put inside, quote, just a plain each one that says local HTML doc.
So we've now got a string called simply HTML as a very small snippet of HTML inside of it.
I'm going to take this variable and provide it to the iFrame as an S R c doc property.
The property allows us to load up some content into an iFrame using some local string, as opposed to
telling the iFrame to go and make a request to some outside your URL.
So in this case, we are still creating an iFrame that's going to have a lot of these same different
security requirements and restrictions.
The only difference is the content for it.
We are storing just directly or we're really just generating directly inside of our application.
It's going to put in here HTML.
And now if I save this look back over and refresh, I'm going to see that content instantly appear inside
the iFrame.
Now there's still an iFrame and we still have a lot of these same different security constraints around
it.
So if I go to my console, there's still this iframe, I can select that separate context.
We're still executing code inside of a different context.
Everything is for the most part, just totally identical to how everything was working before.
The one big difference is that now, because we are generating this content locally.
This rule right here where we are describing how we're going to allow direct access between frames now
because we are generating the content for the iFrame locally, will we pretty much just totally forget
about this case down here?
Because we are generating the content side the iFrame ourselves.
There's not really any concept of a different domain or different port or different protocol because
we're not fetching any content.
We are generating all this content ourselves.
So now.
When we are using the source stock property, whenever we are trying to decide whether or not direct
access is allowed between these two frames, the only question we really have to ask ourselves is whether
or not this Efrem element has that sandbox property and whether or not it has that allow same origin
property.
So right now, our iFrame, as we put it together, does not have sandbox and or in it does not have
sandbox alousi margin.
That means that direct access is allowed between our current iFrame and our parent document and we can
test that out very easily.
Back inside of our console.
Once again, I'll go to top, I'm going to put in a window a equals one.
I'll change into that iFrame context.
A look at parent Dot A..
And there we go.
Definitely access direct communication between the document and the child or something.
The parent document and the child is allowed.
But we can't prevent direct access, which is what you and I want to do if we put on that sandbox allow
or if we just put on the sandbox property and do not put in allow same origin.
Let's try that out really quick, because my frame I will put in.
The.
Sandbox property.
I'll put in just an empty string right now.
Save this look back over, so now direct communication between the contents of that iFrame and the parent
document no longer allowed.
So I'm going to go to top once again.
I'll do a window, a equals one.
I'm going to change into the frame context and do a parent a and there is that air that means that we
are now preventing communication between the parent and the child, even though the content of the child
is being generated locally inside of our.
This is, like I said, a pretty happy middle ground, and the reason that this is such a good middle
ground for our implementation is that the content of this iFrame is going to load up instantaneously.
We do not have to make a request for some outside HTML document.
We are generating the content on our own.
The downside is that inside the context of this iframe, we are not going to be able to use the local
storage and a couple of other browser features to now still in the context of the child iframe.
I'm going to try doing local storage and you'll notice.
Yeah, this is the downside right here.
This is exactly what the downside is.
When we are using this combination of source, stock and sandbox, we cannot access local storage in
a couple other things from inside that iframe.
So this is what we are giving up.
We are trading very large amounts of performance because we don't have to make any outside requests
to get the contents of the iFrame.
We don't have to create all that extra infrastructure.
Unfortunately, we lose access to a couple of different things that we might eventually want to have
access to.
Inside that iFrame really just comes down to whether or not the user ever expects to access local storage.
So I can't say it enough.
It is a trade off in this case.
Kind of decided I can tolerate this.
Know we're pretty much just going to give a note to our users and say sorry, but you can't make use
of local storage.
One possibility here, one very easy workaround is we could try to fill local storage, possibly.
So maybe if we do like local storage, this is just off the top of my head, I could be totally wrong.
So now we can do local store.
No, we can't do it at all.
So, yeah, I guess it's just plain the trade off.
So that's it.
If you don't like the solution, well, you can always I don't recommend you do it right now inside
this course.
But if you don't like the solution, you could of course, read that separate server.
That maybe serves up just this.
iFrame content from localist four thousand six.
And if you go through all these extra steps, you're still going to have access to stuff like local
storage for the code that the user writes.
So it's really up to you.
But again, can't say enough.
Good enough trade off, OK, so that is a lot of stuff around eye frames, but now finally, at long
last, we've come to this kind of solution that's going to work for our application.
We do still have to make a couple of changes to make sure that we can eventually get the users code
inside there and execute it.
So still a couple of things for us to figure out, but let's kind of tackle that stuff in the coming
videos.