1 00:00:00,740 --> 00:00:04,190 Our application is at a really good spot right now, but there are still a couple of things we need 2 00:00:04,190 --> 00:00:04,850 to take care of. 3 00:00:05,420 --> 00:00:10,180 One thing we need to take care of is back inside of our code cell components. 4 00:00:10,490 --> 00:00:11,710 So I'm going to find code cell. 5 00:00:12,770 --> 00:00:16,500 You might recall that inside of here we've got all of our code around producing a bundle. 6 00:00:16,850 --> 00:00:19,920 We then take that bundle and feed it over to our preview component. 7 00:00:20,420 --> 00:00:24,170 So you might recall that we had said previously that we want to eventually take all this bundling logic 8 00:00:24,170 --> 00:00:26,510 and add it into the redock side of our application. 9 00:00:26,970 --> 00:00:28,890 That's going to be the next big thing we start to focus on. 10 00:00:29,630 --> 00:00:34,850 Now, the first thing I want to really think about inside this entire process is how this bundles thing 11 00:00:34,850 --> 00:00:37,240 is really going to kind of integrate into our Reduc store. 12 00:00:37,910 --> 00:00:42,050 We've been saying all along that there might be some kind of bundles reducer and that would store the 13 00:00:42,050 --> 00:00:44,210 bundled code for each individual cell. 14 00:00:44,760 --> 00:00:47,120 But I'm just wondering, is that actually the best solution? 15 00:00:47,120 --> 00:00:48,500 Is that the best way to do this? 16 00:00:48,960 --> 00:00:53,900 I want to take a look at one or two different ways of implementing this bundles piece of state inside 17 00:00:53,900 --> 00:00:54,770 of our reduc store. 18 00:00:55,490 --> 00:01:00,290 OK, so first thing I want to do is point out a real small technicality here. 19 00:01:00,500 --> 00:01:01,610 Real technical thing. 20 00:01:02,720 --> 00:01:09,440 So are bundles, piece of state is calculated from the contents of our code cells to remember we've 21 00:01:09,440 --> 00:01:11,240 got ourselves a piece of state inside. 22 00:01:11,240 --> 00:01:12,350 There is our data object. 23 00:01:12,620 --> 00:01:17,780 Inside, there are some number of code cells and those code cells have a content property. 24 00:01:18,980 --> 00:01:25,280 All of our different bundles are calculated based upon that content property, so we might say that 25 00:01:25,280 --> 00:01:30,530 technically our bundles piece of state is derived from our cells states. 26 00:01:31,190 --> 00:01:32,240 Now, why is this important? 27 00:01:32,360 --> 00:01:33,020 Why do we care? 28 00:01:33,440 --> 00:01:38,060 Well, let's just really clarify exactly what Derive State is really quickly with a much more simple 29 00:01:38,060 --> 00:01:39,200 and straightforward example. 30 00:01:40,330 --> 00:01:45,910 Let's imagine some very simple redux application meant to handle some kind of to do application, so 31 00:01:45,910 --> 00:01:49,990 we got some kind of like to do a listing, like I need to take out the trash, do the dishes, walk 32 00:01:49,990 --> 00:01:51,010 the dog, whatever else. 33 00:01:51,760 --> 00:01:55,950 One way that we might put together this Reduc store would be to add in a to DOS reducer. 34 00:01:55,990 --> 00:01:58,930 That might be an array of strings saying, hey, I need to do these things. 35 00:02:00,010 --> 00:02:04,990 And then you might decide this is not really very good practice, but you might decide that if you ever 36 00:02:04,990 --> 00:02:09,639 want to print out the number of to DOS that a user still has, you might add in something like to do 37 00:02:09,639 --> 00:02:15,350 count in this case, we would calculate to do count based upon our tutu's piece of state. 38 00:02:15,880 --> 00:02:17,890 And right now, our to do count would be three. 39 00:02:18,710 --> 00:02:24,740 So in this case, I would refer to to do count as a derived piece of state because its value is entirely 40 00:02:24,740 --> 00:02:29,240 dependent, 100 percent dependent upon some other value inside of our store. 41 00:02:30,130 --> 00:02:35,290 As much as possible, we really want to avoid putting derive state into our Redock store. 42 00:02:35,440 --> 00:02:37,530 This is just general good practice. 43 00:02:37,750 --> 00:02:40,970 It is not strictly required, but it is very highly recommended. 44 00:02:41,590 --> 00:02:47,200 Instead, we get a very specific tool in the world of Reactant Redux to handle derive state, and we've 45 00:02:47,200 --> 00:02:49,270 actually already made use of it inside this course. 46 00:02:49,660 --> 00:02:50,890 It is a selecter. 47 00:02:51,400 --> 00:02:59,350 You might recall that back inside of our sell list components, we're making use of use type selector 48 00:02:59,350 --> 00:02:59,850 right here. 49 00:03:00,670 --> 00:03:06,790 This selector is taking two pieces of state, the ordering of all of our cells and our data object. 50 00:03:07,090 --> 00:03:11,920 It then combines them together to put out an ordered array of all of our different cell objects. 51 00:03:12,470 --> 00:03:15,160 So this is a really good example of a selector right here. 52 00:03:15,190 --> 00:03:17,500 We have two very pure pieces of states. 53 00:03:17,680 --> 00:03:22,720 We are doing a calculation on them or somehow combining them together and creating a new piece of derived 54 00:03:22,720 --> 00:03:23,110 state. 55 00:03:23,740 --> 00:03:26,440 Again, this is what selectors are all about. 56 00:03:26,470 --> 00:03:28,780 This is the primary job of selectors. 57 00:03:29,650 --> 00:03:31,960 So with that in mind, I got a quick question for you. 58 00:03:32,380 --> 00:03:38,230 Does it actually make sense to create a separate bundles reducer and have some data inside there? 59 00:03:38,830 --> 00:03:42,280 Maybe another way that we could put this together would be something like this. 60 00:03:43,060 --> 00:03:44,020 It's on the left hand side. 61 00:03:44,020 --> 00:03:45,040 We've got a reduc store. 62 00:03:45,070 --> 00:03:47,440 We now only have a cels piece of state. 63 00:03:48,100 --> 00:03:49,930 We then might create a bundle selector. 64 00:03:50,560 --> 00:03:53,740 This thing might take in some code that a user has written into a code. 65 00:03:53,740 --> 00:04:00,520 So send it off to our Eskild bundler it back a bundle, take that bundle and send it onto some component, 66 00:04:00,700 --> 00:04:03,130 for example, maybe the preview component in this case. 67 00:04:04,440 --> 00:04:07,710 So should we do something like this, that is the question I am posing to you. 68 00:04:08,400 --> 00:04:13,680 Well, the answer here is that in general, whenever we are Rickman's electors, we really want to avoid 69 00:04:13,680 --> 00:04:17,350 selectors that have any kind of asynchronous logic inside them. 70 00:04:17,610 --> 00:04:21,959 Instead, we really want to make use of selectors when we have a Synchronoss calculation. 71 00:04:22,390 --> 00:04:28,160 So examples of Synchronoss calculations would be things like summing up the number of elements in array 72 00:04:28,170 --> 00:04:33,090 or calculating the number of elements and combining together to arrays, combining an array object, 73 00:04:33,090 --> 00:04:38,310 which is what we've done inside of our application or any other kind of of manipulation of data like 74 00:04:38,310 --> 00:04:41,580 that as soon as we have asynchronous operations. 75 00:04:41,580 --> 00:04:46,490 So we need to be that we need to do we generally do not want to make use of selectors. 76 00:04:47,190 --> 00:04:48,530 Is there a good reason for this? 77 00:04:48,870 --> 00:04:54,120 Well, kind of comes down to the fact that handling selectors or asynchronous selectors and handling 78 00:04:54,120 --> 00:04:56,060 the output from them is a little bit challenging. 79 00:04:56,580 --> 00:05:00,840 One thing the selectors do behind the scenes is a little bit of performance optimization. 80 00:05:01,920 --> 00:05:06,840 Internally, they say that if a selector is ever called with identical arguments the first time, it 81 00:05:06,840 --> 00:05:09,930 will go ahead and run your selector code so they'll actually do some calculation. 82 00:05:10,200 --> 00:05:15,060 But if you ever try to run that selector again on identical arguments, then rather than redoing your 83 00:05:15,060 --> 00:05:18,900 calculation, it might just return the initially calculated value right away. 84 00:05:19,350 --> 00:05:21,030 So it's a little performance optimization. 85 00:05:21,720 --> 00:05:26,190 Doing stuff like that with asynchronous code can be really, really challenging and sometimes it can 86 00:05:26,190 --> 00:05:28,170 lead to really unpredictable results. 87 00:05:28,920 --> 00:05:35,680 So because our bundler is very much asynchronous in nature, we are not going to create a bundle selector. 88 00:05:36,390 --> 00:05:38,580 Now, maybe that's not a good enough reason for you. 89 00:05:38,580 --> 00:05:40,350 You might say, hey, Steven, come on. 90 00:05:40,350 --> 00:05:40,620 Really? 91 00:05:40,620 --> 00:05:41,010 Like what? 92 00:05:41,010 --> 00:05:41,820 Just asynchronous. 93 00:05:41,820 --> 00:05:45,670 That's what's going to make the divide here of whether or not we decide to use a selector. 94 00:05:46,170 --> 00:05:47,450 Well, let's put this another way. 95 00:05:47,670 --> 00:05:51,540 Let's take a look at another example application we might put together with Redux. 96 00:05:51,810 --> 00:05:56,100 And I think you'll very quickly agree with me that as soon as you start to have asynchronous code in 97 00:05:56,100 --> 00:06:00,500 some other situations, maybe having a selector doesn't quite really make a lot of sense. 98 00:06:01,410 --> 00:06:06,540 So as a quick example here, I want you to imagine that we're building some other kind of application, 99 00:06:06,790 --> 00:06:09,570 maybe it's a very simple search application. 100 00:06:10,110 --> 00:06:12,330 A user is going to type in some kind of search term. 101 00:06:14,480 --> 00:06:19,070 We're going to store that search term inside of our store, they might then click on a search button 102 00:06:19,350 --> 00:06:20,490 when they click on that search button. 103 00:06:20,690 --> 00:06:25,370 We're going to take the search term, make a request to some outside API to search for it. 104 00:06:25,370 --> 00:06:26,630 In this case, maybe cars. 105 00:06:27,080 --> 00:06:30,950 And that will get us, I don't know, maybe a list of photos or a list of videos or something like that. 106 00:06:31,400 --> 00:06:36,560 Well, then take that data that we get back in the outside API and store that list of photos or whatever 107 00:06:36,560 --> 00:06:38,510 else also inside of our Reduc store. 108 00:06:39,640 --> 00:06:44,200 Now, when you look at this application in isolation, without even thinking about what we've been discussing 109 00:06:44,200 --> 00:06:48,610 inside this video, I would say that this kind of approach right here, I'd say this makes sense, right? 110 00:06:48,790 --> 00:06:49,030 Yeah. 111 00:06:49,030 --> 00:06:50,530 We've got a search term piece of states. 112 00:06:50,530 --> 00:06:55,000 We're going to eventually do a search, get a response back, store that data inside of a redock store. 113 00:06:55,300 --> 00:06:56,550 Absolutely make sense. 114 00:06:56,560 --> 00:06:59,620 This is a classic, very simple example of a Redux store. 115 00:07:01,010 --> 00:07:05,930 But you can really apply this same kind of derisive state argument to this application. 116 00:07:06,350 --> 00:07:09,840 We can kind of this is really stretching definitions here. 117 00:07:09,860 --> 00:07:11,210 I completely acknowledge that. 118 00:07:11,450 --> 00:07:17,360 But we could kind of say that our list of photos is 100 percent dependent upon our search term piece 119 00:07:17,360 --> 00:07:17,810 of states. 120 00:07:18,290 --> 00:07:23,300 Now, this is really a very big stretch because we are relying upon some outside service and that service 121 00:07:23,300 --> 00:07:27,800 might decide to give us back a completely different list of videos, even if we do two searches in a 122 00:07:27,800 --> 00:07:28,100 row. 123 00:07:28,370 --> 00:07:30,560 So, again, really stretching this idea here. 124 00:07:30,980 --> 00:07:34,600 But once again, we have some originating value. 125 00:07:34,910 --> 00:07:40,040 We're doing an asynchronous operation, getting back some data and then storing that inside of a reduc 126 00:07:40,070 --> 00:07:40,460 store. 127 00:07:40,640 --> 00:07:44,270 And in this case, I think you'd agree with me that, oh, yeah, this looks totally reasonable. 128 00:07:45,350 --> 00:07:50,360 So we kind of have prior art, I would say there are prior examples that say, oh yeah, well, if you're 129 00:07:50,360 --> 00:07:54,780 doing some asynchronous calculation based on the piece of state storing the result inside of your store. 130 00:07:54,830 --> 00:07:56,030 Oh, yeah, no problem. 131 00:07:56,030 --> 00:07:56,690 Go for it. 132 00:07:57,050 --> 00:07:58,640 That's what this example is really saying. 133 00:07:59,670 --> 00:08:04,470 I think that when we start to think back to our Bundall example, even though this bundles object right 134 00:08:04,470 --> 00:08:10,440 here, yes, it really is and a very much dependent upon the content of all of our code cells. 135 00:08:10,470 --> 00:08:15,870 And you could kind of argue that, yes, this really is the right state again, because this is an asynchronous 136 00:08:15,870 --> 00:08:16,530 calculation. 137 00:08:16,860 --> 00:08:20,160 I don't think this is really appropriate to try to use a selector for. 138 00:08:21,060 --> 00:08:25,740 OK, so I apologize for a long video, I just want to throw this discussion out there because it's something 139 00:08:25,740 --> 00:08:29,880 that generally comes up for a lot of different engineers, like at what point in time should I be using 140 00:08:29,880 --> 00:08:30,410 a selector? 141 00:08:30,600 --> 00:08:32,840 What point time should I not not use a selector? 142 00:08:33,150 --> 00:08:37,770 And I think that very reasonable argument here is to say, well, if you've got asynchronous code, 143 00:08:37,950 --> 00:08:39,780 we probably don't want to use a selector. 144 00:08:40,590 --> 00:08:42,490 Other engineers will disagree with my opinion. 145 00:08:42,510 --> 00:08:45,810 There are packages out there that allow you to write asynchronous selectors. 146 00:08:46,440 --> 00:08:49,300 You can't use an asynchronous selector in react redux by default. 147 00:08:49,710 --> 00:08:52,920 So, again, it really comes down to you, comes down to your personal preference. 148 00:08:53,400 --> 00:08:58,260 But I generally follow the idea of selectors are only for asynchronous code. 149 00:08:59,210 --> 00:09:03,050 All right, so at the very end, now that we've got through this whole discussion, I think the takeaway 150 00:09:03,050 --> 00:09:05,780 here is we do want to have a bundles reducer. 151 00:09:06,050 --> 00:09:06,780 That's the takeaway. 152 00:09:07,100 --> 00:09:07,870 Yeah, pretty much. 153 00:09:07,880 --> 00:09:09,120 We want this diagram right here. 154 00:09:09,680 --> 00:09:14,080 Now, our question is really going to become, how are we going to actually generate these bundles? 155 00:09:14,090 --> 00:09:15,740 What does that whole process look like? 156 00:09:16,190 --> 00:09:19,510 So let's take a pause right here and start to think about this in just a moment.