1 00:00:01,010 --> 00:00:05,300 All right, my friends, we've got this kind of happy middle ground, it is not perfect, but it's pretty 2 00:00:05,300 --> 00:00:07,040 good for actually running users code. 3 00:00:07,670 --> 00:00:12,170 So you might notice that now I'm seeing right here inside this diagram that at some point in time we 4 00:00:12,170 --> 00:00:13,920 need to fetch an HTML document. 5 00:00:14,360 --> 00:00:17,340 So how are we going to somehow get an e-mail document into that iframe? 6 00:00:17,660 --> 00:00:22,560 Well, we could definitely just make a request directly to local three thousand and get that tested 7 00:00:22,580 --> 00:00:25,540 HTML document, which we already have put together. 8 00:00:25,550 --> 00:00:27,140 That's technically what we're already doing. 9 00:00:27,470 --> 00:00:32,420 But remember, this introduces an extra request that we have to make every single time a user changes 10 00:00:32,420 --> 00:00:37,940 some code so that it always just means we're going to take some extra little number of milliseconds 11 00:00:37,940 --> 00:00:38,920 to run users code. 12 00:00:39,200 --> 00:00:44,270 User is on a very slow device and we are eventually running this application and kind of like some cloud 13 00:00:44,270 --> 00:00:46,840 environment or this is a publicly hosted version of our app. 14 00:00:47,150 --> 00:00:51,380 This extra request is just extra time that it's going to take to run a user's code. 15 00:00:51,650 --> 00:00:55,850 I'm kind of curious, is there a way that we can get away with not having to make an extra request to 16 00:00:55,850 --> 00:00:59,220 get that HTML document, but still load up some content inside of an iFrame? 17 00:00:59,570 --> 00:01:03,200 Yes, there is yet again some extra little knowledge around eye frames. 18 00:01:03,260 --> 00:01:04,720 Let's go back over to our code editor. 19 00:01:04,730 --> 00:01:06,510 I want to show you another feature around them. 20 00:01:07,070 --> 00:01:11,810 So at this point time, we've really just been talking about creating an iFrame, putting an SRT attribute 21 00:01:11,810 --> 00:01:16,490 inside there and the iFrame, whenever it loads up, is going to make a request to that URL and then 22 00:01:16,490 --> 00:01:18,320 try to get some HTML and display it. 23 00:01:18,770 --> 00:01:23,780 But there's another way that we can load up content directly into an iFrame without making any request 24 00:01:23,780 --> 00:01:24,120 at all. 25 00:01:24,710 --> 00:01:29,450 I'm going to remove that Sarsae property then underneath my component right now. 26 00:01:29,450 --> 00:01:33,410 Eventually we're going to put this code in a way better place, but just a very quick demonstration. 27 00:01:34,290 --> 00:01:39,380 I'm going to declare a variable heat down here called TML, I'm going to make it a multiline string, 28 00:01:39,390 --> 00:01:41,100 so make sure you've got some back ticks inside their. 29 00:01:42,000 --> 00:01:49,260 Then I'm going to put inside, quote, just a plain each one that says local HTML doc. 30 00:01:50,060 --> 00:01:55,010 So we've now got a string called simply HTML as a very small snippet of HTML inside of it. 31 00:01:55,570 --> 00:02:02,030 I'm going to take this variable and provide it to the iFrame as an S R c doc property. 32 00:02:03,240 --> 00:02:10,229 The property allows us to load up some content into an iFrame using some local string, as opposed to 33 00:02:10,229 --> 00:02:14,190 telling the iFrame to go and make a request to some outside your URL. 34 00:02:15,000 --> 00:02:18,540 So in this case, we are still creating an iFrame that's going to have a lot of these same different 35 00:02:18,540 --> 00:02:20,460 security requirements and restrictions. 36 00:02:20,670 --> 00:02:22,620 The only difference is the content for it. 37 00:02:22,860 --> 00:02:27,150 We are storing just directly or we're really just generating directly inside of our application. 38 00:02:27,660 --> 00:02:29,880 It's going to put in here HTML. 39 00:02:30,360 --> 00:02:36,540 And now if I save this look back over and refresh, I'm going to see that content instantly appear inside 40 00:02:36,540 --> 00:02:37,100 the iFrame. 41 00:02:37,740 --> 00:02:41,850 Now there's still an iFrame and we still have a lot of these same different security constraints around 42 00:02:41,850 --> 00:02:42,060 it. 43 00:02:42,610 --> 00:02:47,100 So if I go to my console, there's still this iframe, I can select that separate context. 44 00:02:47,490 --> 00:02:50,070 We're still executing code inside of a different context. 45 00:02:50,920 --> 00:02:55,260 Everything is for the most part, just totally identical to how everything was working before. 46 00:02:57,390 --> 00:03:02,310 The one big difference is that now, because we are generating this content locally. 47 00:03:03,510 --> 00:03:09,660 This rule right here where we are describing how we're going to allow direct access between frames now 48 00:03:09,660 --> 00:03:14,970 because we are generating the content for the iFrame locally, will we pretty much just totally forget 49 00:03:14,970 --> 00:03:16,290 about this case down here? 50 00:03:16,770 --> 00:03:19,730 Because we are generating the content side the iFrame ourselves. 51 00:03:19,890 --> 00:03:24,510 There's not really any concept of a different domain or different port or different protocol because 52 00:03:24,510 --> 00:03:25,860 we're not fetching any content. 53 00:03:26,220 --> 00:03:28,690 We are generating all this content ourselves. 54 00:03:29,250 --> 00:03:29,790 So now. 55 00:03:31,120 --> 00:03:35,920 When we are using the source stock property, whenever we are trying to decide whether or not direct 56 00:03:35,920 --> 00:03:40,900 access is allowed between these two frames, the only question we really have to ask ourselves is whether 57 00:03:40,900 --> 00:03:46,750 or not this Efrem element has that sandbox property and whether or not it has that allow same origin 58 00:03:46,750 --> 00:03:47,170 property. 59 00:03:47,860 --> 00:03:54,220 So right now, our iFrame, as we put it together, does not have sandbox and or in it does not have 60 00:03:54,460 --> 00:03:56,020 sandbox alousi margin. 61 00:03:56,350 --> 00:04:01,720 That means that direct access is allowed between our current iFrame and our parent document and we can 62 00:04:01,720 --> 00:04:02,830 test that out very easily. 63 00:04:03,100 --> 00:04:04,180 Back inside of our console. 64 00:04:04,930 --> 00:04:08,500 Once again, I'll go to top, I'm going to put in a window a equals one. 65 00:04:09,280 --> 00:04:11,320 I'll change into that iFrame context. 66 00:04:12,470 --> 00:04:14,450 A look at parent Dot A.. 67 00:04:14,930 --> 00:04:15,690 And there we go. 68 00:04:15,860 --> 00:04:21,100 Definitely access direct communication between the document and the child or something. 69 00:04:21,140 --> 00:04:23,090 The parent document and the child is allowed. 70 00:04:24,990 --> 00:04:31,290 But we can't prevent direct access, which is what you and I want to do if we put on that sandbox allow 71 00:04:31,290 --> 00:04:35,430 or if we just put on the sandbox property and do not put in allow same origin. 72 00:04:36,390 --> 00:04:39,900 Let's try that out really quick, because my frame I will put in. 73 00:04:41,890 --> 00:04:42,430 The. 74 00:04:43,650 --> 00:04:45,000 Sandbox property. 75 00:04:46,520 --> 00:04:48,350 I'll put in just an empty string right now. 76 00:04:49,580 --> 00:04:55,520 Save this look back over, so now direct communication between the contents of that iFrame and the parent 77 00:04:55,520 --> 00:04:57,140 document no longer allowed. 78 00:04:57,920 --> 00:04:59,660 So I'm going to go to top once again. 79 00:05:00,840 --> 00:05:02,850 I'll do a window, a equals one. 80 00:05:03,790 --> 00:05:10,630 I'm going to change into the frame context and do a parent a and there is that air that means that we 81 00:05:10,630 --> 00:05:16,330 are now preventing communication between the parent and the child, even though the content of the child 82 00:05:16,360 --> 00:05:18,910 is being generated locally inside of our. 83 00:05:20,540 --> 00:05:26,000 This is, like I said, a pretty happy middle ground, and the reason that this is such a good middle 84 00:05:26,000 --> 00:05:31,110 ground for our implementation is that the content of this iFrame is going to load up instantaneously. 85 00:05:31,340 --> 00:05:34,480 We do not have to make a request for some outside HTML document. 86 00:05:34,490 --> 00:05:36,710 We are generating the content on our own. 87 00:05:37,370 --> 00:05:44,030 The downside is that inside the context of this iframe, we are not going to be able to use the local 88 00:05:44,030 --> 00:05:50,320 storage and a couple of other browser features to now still in the context of the child iframe. 89 00:05:50,810 --> 00:05:53,570 I'm going to try doing local storage and you'll notice. 90 00:05:53,690 --> 00:05:55,360 Yeah, this is the downside right here. 91 00:05:55,370 --> 00:05:57,320 This is exactly what the downside is. 92 00:05:57,860 --> 00:06:05,240 When we are using this combination of source, stock and sandbox, we cannot access local storage in 93 00:06:05,240 --> 00:06:07,740 a couple other things from inside that iframe. 94 00:06:08,120 --> 00:06:09,340 So this is what we are giving up. 95 00:06:09,800 --> 00:06:14,810 We are trading very large amounts of performance because we don't have to make any outside requests 96 00:06:15,020 --> 00:06:16,330 to get the contents of the iFrame. 97 00:06:16,340 --> 00:06:18,400 We don't have to create all that extra infrastructure. 98 00:06:18,830 --> 00:06:24,470 Unfortunately, we lose access to a couple of different things that we might eventually want to have 99 00:06:24,470 --> 00:06:25,070 access to. 100 00:06:25,070 --> 00:06:30,020 Inside that iFrame really just comes down to whether or not the user ever expects to access local storage. 101 00:06:30,570 --> 00:06:31,640 So I can't say it enough. 102 00:06:31,640 --> 00:06:33,590 It is a trade off in this case. 103 00:06:33,620 --> 00:06:36,140 Kind of decided I can tolerate this. 104 00:06:36,480 --> 00:06:41,120 Know we're pretty much just going to give a note to our users and say sorry, but you can't make use 105 00:06:41,120 --> 00:06:41,910 of local storage. 106 00:06:42,200 --> 00:06:47,660 One possibility here, one very easy workaround is we could try to fill local storage, possibly. 107 00:06:48,090 --> 00:06:51,650 So maybe if we do like local storage, this is just off the top of my head, I could be totally wrong. 108 00:06:52,160 --> 00:06:54,260 So now we can do local store. 109 00:06:54,470 --> 00:06:55,360 No, we can't do it at all. 110 00:06:56,180 --> 00:06:58,010 So, yeah, I guess it's just plain the trade off. 111 00:06:58,700 --> 00:06:59,600 So that's it. 112 00:06:59,600 --> 00:07:04,310 If you don't like the solution, well, you can always I don't recommend you do it right now inside 113 00:07:04,310 --> 00:07:04,850 this course. 114 00:07:05,120 --> 00:07:10,340 But if you don't like the solution, you could of course, read that separate server. 115 00:07:12,450 --> 00:07:14,280 That maybe serves up just this. 116 00:07:15,480 --> 00:07:18,180 iFrame content from localist four thousand six. 117 00:07:19,320 --> 00:07:23,190 And if you go through all these extra steps, you're still going to have access to stuff like local 118 00:07:23,190 --> 00:07:25,560 storage for the code that the user writes. 119 00:07:25,590 --> 00:07:26,520 So it's really up to you. 120 00:07:26,520 --> 00:07:27,990 But again, can't say enough. 121 00:07:28,800 --> 00:07:34,650 Good enough trade off, OK, so that is a lot of stuff around eye frames, but now finally, at long 122 00:07:34,650 --> 00:07:38,310 last, we've come to this kind of solution that's going to work for our application. 123 00:07:38,820 --> 00:07:42,330 We do still have to make a couple of changes to make sure that we can eventually get the users code 124 00:07:42,330 --> 00:07:43,740 inside there and execute it. 125 00:07:43,950 --> 00:07:48,630 So still a couple of things for us to figure out, but let's kind of tackle that stuff in the coming 126 00:07:48,630 --> 00:07:49,110 videos.