We've taken care of everything around bundling on the side of things so we can now go back over to Kozel
and make sure that it eventually calls this bundle cell action creator.
We'll also make sure that the code cell component eventually pulls some information out of our bundles
piece of state.
I'm going to first begin by going back over to our components directory and finding our code cell component.
So inside of here, we've got some local state right here that we really don't need anymore, remember,
this local state was because we were previously doing bundling directly inside this component.
We do not need this local state because now the output code and air from a bundle attempt is going to
be stored inside of our Redock store.
I'm going to first begin by removing both of those used state lines.
I'm also going to clean up the set code and set er.
Next up, we're no longer directly doing bundling inside of here.
So we can remove the CONSED output, a weight bundle inside of that timer stuff.
Now, you might notice that down at the very bottom of the file, we've now got some areas around our
preview component that's totally fine.
We'll fix those up in just a moment.
Let's first make sure that we can restore some functionality.
So we need to make sure that whenever this timer is actually executed after that seven hundred and fifty
millisecond wait, we're going to call our action creator of a bundle that we had just put together
so we can first get access to that action creator by pulling it out of this use actions hook.
So in addition to update Zel, we'll also get create bundle.
Then inside of our timer.
Once the timer elapses, we can call create bundle.
We'll provide our cell ID, which is cell ID number, the cell itself is a prop to this function.
This component.
And the second argument will be the actual code that we want to bundle so that be cell content.
We are making use of cell I.D. inside this use effect function now, and so we probably should add it
to this dependency array.
It is not strictly required per say, but if we don't react, is probably going to complaint at us.
When we start to run this code inside the browser, it's going to add into this dependency array cell.
Edem.
OK, so that should kick off our entire bundling process, but now we need to make sure that we also
go back into our Redock store at some point in time and access the state inside there and try to pull
out the completed bundle or maybe that loading flag or whatever else is necessary.
So for that, I'm going to go back up to the top of my file.
I'm going to add in another important statement right after our existing U.S. actions, one right here
and we'll get our use tight selecter.
Remember, use type selector is defined inside of our Hoke's directory.
This is how we pull state out of our store.
So we will import that from folks use type selector.
Then back down right underneath our U.S. skull, we can call you tight selecter.
We will receive state as the first argument.
And then we were going to essentially dig through that state object and look up the bundle result for
our particular cell.
So that would be something like state dot bundles inside their member.
That is give me that big object that has a bunch of keys inside of it.
So we're going to look up.
Sell ID.
So I'm going to take this entire thing right here or whatever we get back from this, and right now
I'm just going to assign it to a variable that I will call Bundall.
And then I'll do a council log of Bundall for right now.
Before we test this out, I'm going to go back down to our Jesus block.
And for just a moment, I'm going to comment about all this previous stuff.
Is there something I want you to see around this council?
First, all right, before we run this, just one other very quick thing before I forget, let's also
clean up some of the important statements we have up here at the top.
We no longer need to import bundle into this component and we no longer need to import used state either.
We still need a preview inside of here.
It's only kind of faded out because we just commented that thing out.
But we are going to uncommon in just a moment, so don't delete the import for preview.
All right, so let's save this, we'll go back with the browser and see how we're doing.
It's going to do a quick refresh.
All right, there we go right away, we get a couple of warnings to find we can ignore those for now.
More importantly, you'll notice that we have undefined, undefined.
And then eventually we start seeing some consulates logs where there's an actual Bundall object, so
loading true, no code, no error, and then eventually loading goes over to false with some amount
of code and no air.
So what's going on here?
Well, it's not the most confusing thing in the world.
Let's kind of think through what is happening inside your application.
Remember, back inside of our states store index or stored dots file.
So inside the store or where we are creating our store, when our application first boots up, we dispatch
a couple of actions right away to create some default cells.
So we get a default cell of type code, text code and text.
So these cells are created immediately inside of application when everything first puts up.
When we first add in these cells, we do not have any actions being dispatch related to attempting to
create a bundle for them or anything like that.
So our initial bundles reducer.
Here's bundles reducer.
This thing starts off with no data inside of it whatsoever.
It is only once we eventually start to render our application.
Show XL list, which is going to show sell item, which is going to in turn show code sell only when
we start to show these components after that seven hundred and fifty millisecond delay, then we're
going to go ahead and finally call the bundle cell action creator.
And that's when we start to dispatch some actions that are going to add in some state to our bundles
piece of state.
So the whole point here, what I'm trying to say is that for the very first seven hundred and fifty
milliseconds or so that our application is being rendered, we have zero data, no data whatsoever inside
of our bundles reducer.
So when we go inside there and try to look up some very particular bundle for a cell, we get back undefined
as we've not received any actions of type bundle, start or bundle complete just yet.
So that's why we are seeing those initial console logs right here of undefined is because our bundle
reducer totally empty right now.
It's only after that seven hundred and fifty milliseconds that we eventually start to dispatch or I
should say call that action creator of bundle, create or create a bundle.
That thing is going to dispatch the bundle start, which is going to give us some initial object.
Same thing right here says for the second cell, and then eventually, after another millisecond or
so, we finally complete our bundle and dispatch another action.
So here's my point.
Here's the big question.
We're currently getting some undefined values out of our bundle reducer.
Is that something we want to allow?
If we want to allow the US to get some kind of undefined values out of that bundles piece of state,
then we should probably think about updating the type definition of our bundles reducer.
Because right now our type definition is really saying that whenever we look inside of there, we are
always going to get back some kind of defined bundle property.
If I mess up a bundle right now, it's saying that this is always going to be an object of type, blah,
blah, blah.
But it's very clear, based on this council log that that's not always the case, there are going to
be some scenarios where Bundall might be undefined.
So we need to decide whether or not we want to update our type definition to reflect that, or if we
want to try to take some kind of other approach that makes sure that we always get back a defined Bundall
object no matter what.
So long story short, we got a little bit more thinking to do here.
Let's take a pause and address this in just a moment.