We've now gotten action creator to load up our list of employees we made a ref to our collection of
employees and then we watched for any new value to come across.
Again one thing to clarify here is that this is not only triggered when a new value is added by someone
else.
It is the generic event to say just go and fetch some data from this location.
In addition this Wotcher right here this event handler will exist for the life cycle of our entire application.
So we watch for this thing one time and then any time any data is added to that employees read right
here by anyone by anything.
It's going to dispatch a new action.
So one action creator watches this data source for our entire applications lifecycle.
Our next step is going to be to call this action creator and receive the data in the reducer.
Let's first call the action career from the employee list component.
You know what that means.
We're going to have to import the action creator and the Kinect helper in here and call it from within
the company itself.
So import connect from re-act redux.
Then we will import employees with employees right.
Yes.
Employees fetch from actions that are at the bottom.
We can add on our connect helper.
We don't have a map state to prop's just yet.
So we'll even know for right now.
And as the second argument will give employees fetch and then let's not forget to wrap employee list
with a set of peron's as well.
And then finally inside of our component we will we want to fetch this list of employees or we want
to start watching for employees to be loaded.
The instant that this component is about to be rendered to our device.
So we'll add our lifecycle method component will mount.
So as soon as this component is about to be shown on the device we will attempt to go get all those
employees.
Stock profs DOT employees.
That's like so cool.
Now last thing we have to do is add a new reducer to receive this list of employees.
The end is near reducers going to have the sole purpose of holding our list of employees that are active
for this user.
So I'll make a completely new reduce or we're not going to try to use the employee form reducer here
because this has nothing to do with a form it's only asked to do with the employees.
So in my reducers folder I'll make a new file called employee reducer and then side of your we'll put
in our boiler plate for reducer.
First I will import employees fetch success from leide types file and then we'll place our initial state.
We are going to use a object as our initial state here and you might be thinking well you'll Stephen
we are loading up like a list of employees when it just makes sense to have an array of employees.
It's definitely very good thought.
But let's let's go on for just a little bit.
Bear with me for a moment here and then we're going to see exactly how firebase loads this data for
us.
So next we will export default our state and we'll defaulted to our initial state got our action.
And then here comes the fun part.
I'm going to switch over auction type by default.
I want to return state and if we have an action with case employees that's success.
All right this this right here is where things are.
I mean it's interesting so for right now I want to just console log or action and return my stake.
OK so we're not going to do anything with the action just yet.
I want to specifically look at the action.
I want to see what data we're getting from firebase.
Remember this action is going to come across right here.
It is going to have as the payload.
Whatever was on that snapshot that vals whatever came out from snapshot value.
That is what the payload is going to be.
And I want to specifically look at what that value is and what it's going to do for us.
Now let's you have to do is add this reducer to our combined reducers call.
So in my reducers index start J.S. file we will import employee reduce our From employee reducer and
I'm going to say my employees piece of state is going to come from my employee reducer.
All right.
So we've already created some number of employees right.
Like we've made some using the form.
We've seen them in firebase.
So I think that we can immediately attempt to run the thing right here and get our tonsils.
We should see at least you know some number of employees come across.
It's all very Am I con. I will bring up my simulator.
Let's do our refresh then I log back in.
So the instant that I log in I'm going to transition over to the employee list component and as soon
as the employee list is about to be rendered on the screen in my device it will call the action Crear
to load up the list of employees will fetch a list of employees and eventually we'll see that conc logs
me and then expect to see the consul log right away to log in I see employee list on the screen.
And here's the action.
So the payload right here is all we really care about in this object right here is what is containing
our list of employees.
So this is a very common data structure that you're going to see from firebase rather than giving us
an array of employees which would be you know quite useful.
We get back an object containing all the different employees that we have the keys of the object are
the IDs of each employee.
So if I want to make reference to like Jane specifically I could reference an ID of Katie T-P blah blah
blah blah.
And same thing for Alex John and so on.
So rather than coming back as an array of employees we get back an object
this is really a very common data structure that you're going to see in a lot of redux apps.
So you're going to see a lot of redux applications using an object where the keys are the idea of the
record as opposed to an array.
The reason that you end up with an object for storing data like this is to help with redux as a requirement
of always returning a new object from reducers.
So this is it is not only because of reducto we do this but it sure is a nice thing.
That's what I should really be saying here.
The reason for this is you know just think about if we wanted to have an array of employees an update
a very specific employee using a reducer.
We would have to return a new array member because we want to satisfy reductions requirements.
So we would have to go through our existing array find the record we want to update we would splice
it out and then splice in the update to record and then also make sure that we return a new array so
we would have to use the you know dot dot dot dot on there as well with the array because the spread
syntax work works with the race as well in contrast updating a object full of records is a lot easier
when we want to update some very specific record.
I mean to say this is just for example right here we're not going to actually have this line of code
I'm insane for example.
So when we organize by ID we can do something like this.
So rather than walking through the array finding the record we want to replace.
We can just say take all the records out of the existing object do all the employees we have.
Create a new key value pair where the ID are excuse me the key is the idea of the record that we want
to update and the value is the updated record itself.
So if the syntax right here it is so much easier to do than try to walk through an array and find the
record that you want to update.
So keeping track of your data using an ID based approach like this is pretty darn useful.
So we don't really need to do any of that stuff for right now.
We just care about the list of employees that are coming back from firebase.
So we will replace this with just action payload.
So this is why we made our initial state an object it is because eventually we're going to end up with
an object containing all the different employees and our application.
So this wraps up our employee reducer.
We're now keeping track of all the different employees in our application.
Let's continue the next section and start working on rendering this list of employees to our users