We just put together some code to handle this update, cell action, and as you can see, yes, we did
really end up with some complicated update logic right here now as we start to think about moving on
to handling our delete cell action type.
I just want to point out that the update logic is going to be even more complicated in this case.
And the reason for that, remember, when we delete a cell, we actually have two locations where information
about a cell is recorded.
It is first recorded inside the data object.
That's where the actual cell exists.
We then also have that order array, which is going to indicate the order in which these cells should
be presented on the screen.
So inside there is going to be the ID of the cell and we need to delete that.
So not only do we have to make an update to our data property, we also have to make an update to our
order property as well.
So if you thought that this update right here was a that confusing, it is only going to get worse.
So with that in mind, I got a little question.
I'm wondering, is there some better way to write out our producer?
Is there some way that we can write out reducer that's still going to follow all the rules of redux
where, remember, if we make any change to our state, we have to return a brand new object.
Is there some way we can do that but not have to write out this really complicated logic?
Well, naturally, there is.
Let's take a look at a library that is going to allow us to directly manipulate the state object.
In other words, change it directly instead of trying to write out all the spread logic and produce
a brand new state object.
So at my browser, I'm going to open up a new tab and navigate to NPM J.S. Dotcom.
I'll then do a search for IMR.
That is the name of the package we are going to use.
Here's the link for it all, then scroll down a little bit and find the documentation section.
I'm going to go to the documentation and then once here, I really recommend that you just go directly
to the update patterns link on the left hand side.
Well, then scroll down just a little bit.
So the interlibrary has a ton of functionality tied to it, but its most basic and probably most important
feature is the default expert from IMR itself.
The default expert is a function called produce.
Produce is a function that we are going to call with a function.
So notice how they are calling produce right here and they are passing a function in calling produce.
Passing a function in.
This produce function is going to take an hour reducer.
Produce is then going to automatically call our reducer at some point in time, and it's going to give
to us still a state object that is identical to the state object that Redox normally gives to us with
one very big difference.
We can directly modify the state object as much as we want so we can reach into the state object, mutate
and change properties at will when we then return that object or really just and we don't necessarily
have to return it.
Just a quick side note.
After we mutate, it will then take that object.
It will then magically update our state object for us in a way that is compatible with Redox.
So long story short, IMR allows us to make very direct updates to our state object so we can avoid
having to do these really long and complicated spread statements.
So, for example, if we were using IMR here, we could have done something like state dot data.
Rated not content equals content.
This is all we have to write, if we were making use of IMR after we make this update, Emerson going
to take the update we have made reassemble that state object in a way that is friendly to Redox and
everything is going to work as we would normally expect it.
The only change here is that we do not have to manually do all the spread stuff and produce a brand
new state object on our own.
So as you can guess, IMR is going to save us a lot of time and really simplify a lot of our different
reducer cases because we can just write out very simple updates that look like that.
So let's install IMR into our project and then use it inside this reducer.
It's really easy to use.
Can't say that enough, and that's why we're going a little bit light on the introduction, otherwise,
if this was a more complicated library, would have several other videos to introduce it.
But again, it's just very easy to get started with.
So not a lot to say about it beyond to just use it and see how it works.
OK, so let's go over to our terminal.
Back over here, I'll do an install.
In this case, we'll just get the latest version.
This thing has not had bright breaking changes in a long time, so I'm not really going to say what
the version all that much.
Once I've installed it.
Well, then flip back over to our Ed.
Still inside of our cells reducer at the very top, I'm going to import produce from Himer.
I'll then go down to where we define producer.
We're going to go right after we where we declare to reduce our variable and I'm going to wrap our entire
reducer with that produce function Sopot and produce like.
So I'm going to put the closing parentheses down at the very end of our producer.
So down right there.
And that's pretty much all we have to do to make use of it.
So now we can do direct updates to the state object as much as we please.
And again, everything is just going to work as expected so we can rewrite this entire return statement
right here.
And again, we don't technically have to return anything.
We can just directly make updates to our state object.
So I'm going to delete that entire return statement and replace it with.
Data at ID, so it's going to find the appropriate cell inside of our data object.
Well, then, access to content property and I'll make an update to that content property.
And that should be it.
So now in this case, we are not really returning any value and we don't have to return a value now
because again, IMR is going to automatically just figure out the updates we have made and return a
state object for us.
So we no longer really need this return type annotation on our.
Function anymore, we don't have to say that we're going to return an object of self state because in
some cases we are going to return anything at all.
So I'm going to remove that return type annotation.
Now, we might still end up with a little warning here that just because in this case, I'm not actually
returning anything in this case anymore.
So obviously, right after doing that update, I can add in a return like so and I'll make sure that
I don't just fall through to all my other cases.
OK, so that should be it.
Now, if you still want to have the return type annotation on here, just to make sure that when you
do want to return a value for some reason, you can still added on to the very end.
And you can say that we're going to either return an object of type cell status or void.
And that's going to just say, OK, if you want to return a value, we'll check it.
But if you don't return anything, that's totally fine.
That works as well.
OK, so in theory is going to work just fine, but obviously we don't really have any code to test all
this stuff out just yet.
So we're going to assume that everything is working as usual until we can actually run this code inside
of our browser.
Let's take a pause here.
Now that we are making use of IMR, we'll come back to the next video and start to wire up delete cell
as well.