We're now able to navigate to the employee create form either in the context of like trying to add a
new employee.
Like when you hit the button on the top right hand side of the app or in the context of trying to show
an edit an existing one.
And that's what we're really trying to get to whenever we tap on an existing employee.
Like I want to show a form where the user can edit the existing employee or just look at their details
or whatever else right.
So it kind of makes sense to kick our user over to the employee create form and include this employee
along with it.
We don't really need the console log anymore in here.
So I'm going to take the log out just to do a little bit of cleanup.
Now this topic of or this idea of trying to reuse this form when we want to edit or like show an employee
is a little bit divisive in the web development community.
So we're going to do a little bit of lecture for a moment just do a little bit of a detour to talk about
this the somewhat controversial decision that we need to make right now is deciding whether or not we
should reuse this component for both creating and editing an employee.
That's that's the path I've kind of directed us towards but we have to stop for just a second and ask
ourselves is that the right decision.
Do I want to have one component that is responsible for both creating an employee and also editing one.
So let's take a look at a diagram that's going to help us you can hash out the differences here.
The reason this is a big deal or like deciding whether or not we should have a single component to handle
both operations is because there's a lot of logic inside this form that is very common to both creating
and editing and employee.
Right like on the left hand side here I've got the form to create employee on the right hand side is
the form that will like an employee.
Both forms are going to show name phone and shift.
So both them definitely show that.
The only big difference between them is the presence of the different buttons at the bottom.
So on the create form we just have like save or I think we actually called it create employee create.
So we call it in on the Edit side.
We would probably have a very similar button but it would do something very different.
Right.
It would try to update an existing employee as opposed to create one from scratch.
We would also have the delete button down here and the original box I put together also showed a button
to text this particular employee their schedule as well.
So clearly some aspects of this form are shared between these two different operations but some aspects
are not like the other buttons at the bottom are not shared.
So that is why we have to ask ourselves does it make sense to try to reuse this component.
It is kind of a difficult decision because while there are similar components on either side we would
kind of.
To make this work we would have to have a lot of conditional logic inside of this component to say OK
are we in create mode or are we in edit mode.
And depending on which one we are what should we do when someone taps on this button.
Or what set of buttons should I show or do we need to somehow attempt to pre-filled the inputs on here
with the employee that we're trying to edit.
So there clearly would be both some benefit in terms of code sharing but also some cost in increased
complexity inside this form.
So that is that's the pros and cons here.
That's the that's what you have to weigh.
This is not a decision that is limited to just react.
This is something very common to all types of frameworks.
You know making the decision whether or not you want to try to reuse the two forms that are the two
different modes creation and editing.
So there is one other factor to think about when you're attempting to reuse these forms.
Let's let's see what it is you can pull up another diagram here your ego.
So this is how the employee form is working right now.
The user goes to the form the form gets its values from the reducer and by default it's empty.
The user will then enter some values so they're going to select a thing and type something into it and
boom they're good to go.
Users submit the form and we save the data that was in the reducer right like we do that in the action
creator but we pull the data from the reducer and save it.
So now the etic case is a little bit more complicated in the edit case whenever that user comes to this
screen they are intended to edit a very certain record.
So we should have the values already in each of the inputs on the screen right here.
But the value of each inputs is coming from the producer not some like arbitrary model that we passed
in as a prop to this component right.
We have to somehow pre populate the state in the form reduce or in this case the other really important
aspect here is that the user is changing these values and whenever they change the values in here this
is something that I really want to just point out as kind of a side topic whenever we use it user starts
to edit the values in this form.
Above all we want to avoid editing our employee model.
So remember we are like passing an employee in here that like this props the employee above all.
We always want to avoid editing that existing model in memory and the reason for that is that at any
point in time our user could like change the name from Sarah to Jill or or Amanda.
Right.
But then they say oh you know what.
Siri actually did not change her name and they end up putting the back button.
If you had if you had changed that original employee model that was sitting in memory you've now got
a like dirty model and you would have to reach back out to firebase somehow and reload that model from
firebase.
So when we think about the case here we need to somehow pre populate our state in the former douceur
and we want to make sure that whenever user edits the form we are not editing the employee in memory
like the one that is stored in our employees reducer We are editing the employee that is stored inside
the form we do sir.
Then when the user finally clicks save we could submit the form and save the data for the reducer.
So a lot of different topics that we covered here.
Let me give you just one big summary.
The edit form and the create form behave just a little bit differently.
Just enough for us to have to wonder about how much code we can reuse between each of them.
And really just enough to make us feel guilty if we dont try to reuse at least a little bit of code.
So let's continue in the next section and try to figure out what the best case or what the best best
path forward is for making at least some re-usable or some attempt at reusing some of the code that
weve already got in our form.