Our application is at a really good spot right now, but there are still a couple of things we need
to take care of.
One thing we need to take care of is back inside of our code cell components.
So I'm going to find code cell.
You might recall that inside of here we've got all of our code around producing a bundle.
We then take that bundle and feed it over to our preview component.
So you might recall that we had said previously that we want to eventually take all this bundling logic
and add it into the redock side of our application.
That's going to be the next big thing we start to focus on.
Now, the first thing I want to really think about inside this entire process is how this bundles thing
is really going to kind of integrate into our Reduc store.
We've been saying all along that there might be some kind of bundles reducer and that would store the
bundled code for each individual cell.
But I'm just wondering, is that actually the best solution?
Is that the best way to do this?
I want to take a look at one or two different ways of implementing this bundles piece of state inside
of our reduc store.
OK, so first thing I want to do is point out a real small technicality here.
Real technical thing.
So are bundles, piece of state is calculated from the contents of our code cells to remember we've
got ourselves a piece of state inside.
There is our data object.
Inside, there are some number of code cells and those code cells have a content property.
All of our different bundles are calculated based upon that content property, so we might say that
technically our bundles piece of state is derived from our cells states.
Now, why is this important?
Why do we care?
Well, let's just really clarify exactly what Derive State is really quickly with a much more simple
and straightforward example.
Let's imagine some very simple redux application meant to handle some kind of to do application, so
we got some kind of like to do a listing, like I need to take out the trash, do the dishes, walk
the dog, whatever else.
One way that we might put together this Reduc store would be to add in a to DOS reducer.
That might be an array of strings saying, hey, I need to do these things.
And then you might decide this is not really very good practice, but you might decide that if you ever
want to print out the number of to DOS that a user still has, you might add in something like to do
count in this case, we would calculate to do count based upon our tutu's piece of state.
And right now, our to do count would be three.
So in this case, I would refer to to do count as a derived piece of state because its value is entirely
dependent, 100 percent dependent upon some other value inside of our store.
As much as possible, we really want to avoid putting derive state into our Redock store.
This is just general good practice.
It is not strictly required, but it is very highly recommended.
Instead, we get a very specific tool in the world of Reactant Redux to handle derive state, and we've
actually already made use of it inside this course.
It is a selecter.
You might recall that back inside of our sell list components, we're making use of use type selector
right here.
This selector is taking two pieces of state, the ordering of all of our cells and our data object.
It then combines them together to put out an ordered array of all of our different cell objects.
So this is a really good example of a selector right here.
We have two very pure pieces of states.
We are doing a calculation on them or somehow combining them together and creating a new piece of derived
state.
Again, this is what selectors are all about.
This is the primary job of selectors.
So with that in mind, I got a quick question for you.
Does it actually make sense to create a separate bundles reducer and have some data inside there?
Maybe another way that we could put this together would be something like this.
It's on the left hand side.
We've got a reduc store.
We now only have a cels piece of state.
We then might create a bundle selector.
This thing might take in some code that a user has written into a code.
So send it off to our Eskild bundler it back a bundle, take that bundle and send it onto some component,
for example, maybe the preview component in this case.
So should we do something like this, that is the question I am posing to you.
Well, the answer here is that in general, whenever we are Rickman's electors, we really want to avoid
selectors that have any kind of asynchronous logic inside them.
Instead, we really want to make use of selectors when we have a Synchronoss calculation.
So examples of Synchronoss calculations would be things like summing up the number of elements in array
or calculating the number of elements and combining together to arrays, combining an array object,
which is what we've done inside of our application or any other kind of of manipulation of data like
that as soon as we have asynchronous operations.
So we need to be that we need to do we generally do not want to make use of selectors.
Is there a good reason for this?
Well, kind of comes down to the fact that handling selectors or asynchronous selectors and handling
the output from them is a little bit challenging.
One thing the selectors do behind the scenes is a little bit of performance optimization.
Internally, they say that if a selector is ever called with identical arguments the first time, it
will go ahead and run your selector code so they'll actually do some calculation.
But if you ever try to run that selector again on identical arguments, then rather than redoing your
calculation, it might just return the initially calculated value right away.
So it's a little performance optimization.
Doing stuff like that with asynchronous code can be really, really challenging and sometimes it can
lead to really unpredictable results.
So because our bundler is very much asynchronous in nature, we are not going to create a bundle selector.
Now, maybe that's not a good enough reason for you.
You might say, hey, Steven, come on.
Really?
Like what?
Just asynchronous.
That's what's going to make the divide here of whether or not we decide to use a selector.
Well, let's put this another way.
Let's take a look at another example application we might put together with Redux.
And I think you'll very quickly agree with me that as soon as you start to have asynchronous code in
some other situations, maybe having a selector doesn't quite really make a lot of sense.
So as a quick example here, I want you to imagine that we're building some other kind of application,
maybe it's a very simple search application.
A user is going to type in some kind of search term.
We're going to store that search term inside of our store, they might then click on a search button
when they click on that search button.
We're going to take the search term, make a request to some outside API to search for it.
In this case, maybe cars.
And that will get us, I don't know, maybe a list of photos or a list of videos or something like that.
Well, then take that data that we get back in the outside API and store that list of photos or whatever
else also inside of our Reduc store.
Now, when you look at this application in isolation, without even thinking about what we've been discussing
inside this video, I would say that this kind of approach right here, I'd say this makes sense, right?
Yeah.
We've got a search term piece of states.
We're going to eventually do a search, get a response back, store that data inside of a redock store.
Absolutely make sense.
This is a classic, very simple example of a Redux store.
But you can really apply this same kind of derisive state argument to this application.
We can kind of this is really stretching definitions here.
I completely acknowledge that.
But we could kind of say that our list of photos is 100 percent dependent upon our search term piece
of states.
Now, this is really a very big stretch because we are relying upon some outside service and that service
might decide to give us back a completely different list of videos, even if we do two searches in a
row.
So, again, really stretching this idea here.
But once again, we have some originating value.
We're doing an asynchronous operation, getting back some data and then storing that inside of a reduc
store.
And in this case, I think you'd agree with me that, oh, yeah, this looks totally reasonable.
So we kind of have prior art, I would say there are prior examples that say, oh yeah, well, if you're
doing some asynchronous calculation based on the piece of state storing the result inside of your store.
Oh, yeah, no problem.
Go for it.
That's what this example is really saying.
I think that when we start to think back to our Bundall example, even though this bundles object right
here, yes, it really is and a very much dependent upon the content of all of our code cells.
And you could kind of argue that, yes, this really is the right state again, because this is an asynchronous
calculation.
I don't think this is really appropriate to try to use a selector for.
OK, so I apologize for a long video, I just want to throw this discussion out there because it's something
that generally comes up for a lot of different engineers, like at what point in time should I be using
a selector?
What point time should I not not use a selector?
And I think that very reasonable argument here is to say, well, if you've got asynchronous code,
we probably don't want to use a selector.
Other engineers will disagree with my opinion.
There are packages out there that allow you to write asynchronous selectors.
You can't use an asynchronous selector in react redux by default.
So, again, it really comes down to you, comes down to your personal preference.
But I generally follow the idea of selectors are only for asynchronous code.
All right, so at the very end, now that we've got through this whole discussion, I think the takeaway
here is we do want to have a bundles reducer.
That's the takeaway.
Yeah, pretty much.
We want this diagram right here.
Now, our question is really going to become, how are we going to actually generate these bundles?
What does that whole process look like?
So let's take a pause right here and start to think about this in just a moment.