OK, so this nicely works, we're getting back stats for each user, but there's tiny dewji in our setup.
What do you think is going to happen if the user just sign up for the account?
So essentially there are no jobs or if he or she is not adding the job?
So again, the scenario that I'm trying to represent is if there are no jobs, I know we can clearly
see that with Peter.
That's the other use that I have.
So I'm going to go here with email and I'm going to go with beta Gmail dot com.
The secret a secret.
OK?
That's awesome.
And if I go and show stats, I've got nothing.
And even if I at one job, which definitely we can do.
So let's go here with career job and I'm going to keep the same values just so it's easier.
Yep, we create that, we go, it starts and now we're definitely should have one for banning.
So life is great.
But eventually, this will break our front and application.
That's the problem here.
And technically, you can make an argument that we can set up defaults here on front, then that's a
definite case.
But again, this comes down to preference where I'd rather set up those values on the server on a backhand.
So here's what we're trying to achieve if we take a look at the Redmi.
The next step is going to be following where I'll create default, that object.
I'll pretty much mimic the same properties pending interview and decline, and I'll check if the property
exists in the stats after we have run the reduced awesome use that value, if not, then use zero.
And the goal here is that if the user just logged in or he or she just doesn't have any jobs, at least
we have some kind of values.
So if I work on a front end, at least we can display zeros again.
Yes, we can set up those default ones on a random browser.
Rather do that here in a server.
And we'll also right away add these monthly applications, which will work on next.
As far as the charts, simply because, again, since I'm setting up the whole functionality anyway,
we might as well add this as a dummy value and then we just add the functionality.
So that way, I don't need to go through my whole application just to change this one property, just
like we did in the previous setups.
So let's go to a jobs controller and let's set up that object where effectively we want to go with const
and default starts, and then that one will be equal to an object and then let's go one by one.
So we have one pending that will be equal to a start spending or a zero.
So we'll go here with zero unless copying Parrish.
Let's add those zeros here, meaning comma sorry.
And the second value will be into real.
So let me probably use my two characters here.
So I'm going to go here with Interview, which might be in the stats as appropriate might not.
Then that depends whether the user has created those jobs.
And then we want to go with the combined, let's say that I want, and now it will notice, by the way,
the North is missing over here and no one will notice is the fact that even if Peter doesn't have any
jobs, at least we'll get back to zeros.
Now, let's not forget about those monthly applications.
So let's go here with let and monthly applications.
And yes, again, we're using let because eventually we're off to do more work.
We will use the aggregation pipeline, but we'll have to manipulate the data.
But so let's go here with default starts first and then also pass in those monthly applications.
Let's save it.
And now if I go back to the postman instead of just getting one value, we're going to get at least
some zeroes.
So I'm going to have pending interview and declined and then left me quickly again.
Log in as John, or I'm sorry, I'm logging back here as beta.
My bad.
So let's go here with John.
Let's log in and now see that everything still works as far as our stats.
So now I'm just getting these defaults stats.
But in here, since John does have values, everything is spelled out, and that's how we can set up
the default stats.
So our front end doesn't break if the user hasn't created the jobs.