We've now got the ability to show a model to the user or basically as confirm a message box right here.
But we don't actually have any way to dismiss it or kind of say yes I do want you're right it doesn't
actually do anything just yet.
So if we open up to confirm itself we'll see that we passed it two separate buttons one of which we
call on except whenever a user clicks us or presses Yes.
And the other we call on decline whenever they press no.
And both unaccepting on decline just to be clear are coming from the prop's that we passed to this component
and this confirmed component.
So we do have a component that we can customize and have very specific behavior whenever user clicks
yes or no.
But we're not actually implementing that behavior just yet to implement that behavior.
We'll flip back over to employee at it and I'm inside my render methods down a ways on the page a little
bit and here's where we have that confirmed tag as we replace the confirm itself.
So we need to pass confirm right here a on except and on decline crop.
And then in both those callbacks that will pass to them we need to basically do the appropriate thing
right we need to either dismiss the confirmed message or we need to actually go in to lead the user.
So let's get to it first.
We will pass it a on except and on decline Propp.
So it's due on except and on decline that we need to pass these things actual callbacks of course.
So I'll pass on we'll say just on except we're you know I'm better.
Yeah nonexempt is reasonable.
I would I'd be really happy with that except I would also be happy with Onix Seth to confirm or confirm
X get except excuse me also on employee delete that one might be a little bit misleading because that
kind of implies that that is the action or me the event that would be called after the employee was
deleted.
So I think that except is reasonable right now.
So a call I accept and on decline go so we'll take your the easy one first which is on decline.
When the user presses on decline presumably their intent is to just close that motile close that message
box that pops up to them.
So let's scroll up a little bit.
We're going to find both these callbacks as methods on this class.
I'm going to call them up right above the render method and I'll place my on except and my on decline.
So again we'll start with the on decline.
Now this one's a little bit easier of the two.
All we want to do here is hide that motile box and keep in mind the motile is only visible when this
starts state DOTs show motile is true.
So really all we have to do here is flip this boolean to false and the motile will just go away because
now visible is false and it's going to be hidden from the user.
So we're not actually per se like the rendering that confirmed to the user or you know like kind of
like rendering and sticking onto the screen.
We're just kind of toggle the visibility with the single prop.
So let's come back up to decline and I'll say this Daut set state so modal is false.
So no do not show the.
I don't want to see the model on the screen so I have a reasonable belief that this is going to work
right here.
So maybe I won't tested just yet.
Let's do the Onix first and then we'll do a full test.
So in the case of on except this is where we want to actually initiate the employee deletion process
as Oregon to say like amyloids It's been nice knowing you but you're out of here goodbye so to speak.
So we don't really have anything yet to handle deletes But what we clearly need to do is somehow hop
over to firebase and say okay this record right here like Jane you're fired you are deleted.
We need to just delete this record right here.
So that's our that's our end goal to work with our firebase data.
We'll use the same pattern that we've used for all the other locations where we've worked with firebase.
We will create an action creator.
So in my employee actions file we will create a new action create are called employee delete.
Scroll down to the bottom and define export Konst employee deletes.
Now we need to know exactly which employee we are attempting to delete here.
And rather than passing in the name which you know we might have many employees named Jane or Matthew
or whatever other name we need to pass in an ID because the idea is very unique and it's going to say
this very particular employee This is who I want to lead.
So I'm going to assume that this thing is called with a new ID which is the ID of our employee next
to the rest of this.
Me very similar to the set up we've already done.
We are going to get a ref to this very particular employee right here and then we'll use a firebase
method to say please you know knock this guy out.
Just take him out.
We don't want him anymore.
So we use the same pattern as we had before where we grabbed the current user create a ref and then
do something with that ref.
So first we'll say Konst current user
and then we return a function to meet the requirements of redux thung.
Because again this is going to be an asynchronous action creator and we'll say firebase DOD database
ref and in here we're going to pass in the same type of interpretated string as before and as matter
of fact is very similar to our employee save one because we want to reach in to a very particular employee
and we want to get a reference to a very particular employee.
So I will say look into my collection of users
find my current user dot Id like you know find this user's bucket of data grab their employees and then
find this very particular employee.
So that's where the ideas coming from right there.
Now here's the new part of firebase API.
What we haven't quite covered yet is how do we remove records.
Well it's really not that bad.
We've got to call him if that's it.
So we can get a ref to a node and firebase.
So this is like pointing out a very particular part of our firebase data structure and then we move
on.
And this node and any children that it has puf just go away.
They get removed now after this.
We need to make sure that we actually do something after here.
Right like just removing the employee isn't isn't quite enough.
We need to actually make sure that the user acknowledges OK I understand the employee is deleted fantastic.
So to handle that I think it's appropriate that we navigate the user back to our employee list you know
just be kind of like okay they're gone kick them back to the employee list and they're not going to
see the employee on that list anymore.
They're going to reason we believe up they're gone.
So chain on a door then an inside of your we'll call actions dot employee list.
Again I don't want to add another viewer to my stack.
I'm going to type and type reset as in I'm not going forward per se I'm just navigating to a new view
starting a new bucket of views for me.
He also notes that we didn't use dispatch here so we can probably take this argument out.
We're not using dispatch just because we know that whenever we make a change to our list of employees
that existing fecche employees action greter right up here the value event is going to trigger again.
We're going to see another dispatch and we're going to get the new collection of employees showing on
the screen so we know that once we delete the employee everything should just kind of update the way
we expect.
So I don't really need to call another action Creator in here and I don't really need to dispatch me
that I could dispatch an event and like say the error case or maybe I want to show a big check box to
say yes the user or the employee was deleted.
But again that's kind of you know up to you as a developer.
So let's do a test.
I'm going to refresh my simulator and I just realized before we can do that.
Let's take a quick break because this is turning a little bit long.
Let's take a quick break and hook up this action crater in the next section and then test all this behavior