In the last section we continued developing this analogy to better understand how redux works internally
in this video.
I want to get a better understanding of what is going on with this form right here.
Remember we had said that a customer is going to fill out a form handed off to the former receiver.
The pharmacy will make a copy of it and then hand it off to each department.
Along with that department's little slice of data.
All right.
So we're going to imagine that every form that gets filled out by a customer is going to have two different
parts.
It's going to be essentially a sheet of paper with some fields at the top that the customer has to write
in and then a field at the bottom that has more information that the customer has to enter.
So we'll say that every form has a type assigned to it.
The type of the form essentially declares what the purpose of the form is.
Remember our insurance company has two broad objects that a customer is going to use to interact with
it.
A customer can create a policy and a customer can also create a claim.
So chances are that we would want to have different forms for creating a policy and for creating a claim
as well.
So we'll do it we'll declare it the purpose of each form as a type.
At the very top of each form and then inside the body of the form which we might refer to as the payload
We'll have the customer write down some information relevant to them and what they're trying to do.
So in the case that a customer is trying to create a claim and get some money from the insurance company
we might want the customer to give us their name so that we can identify them.
And we also might want the customer to tell us how much money they think that they should be paid which
you might refer to as say our claim amount now in total.
I think that our company would need three different types of forms.
We would need a form for a customer to create a policy.
We would need a form for them to create a claim and then chances are that eventually a customer would
not want to be a member of our insurance company anymore.
And so they might submit a another form to delete their active policy.
So in total three types type 1 Type 2 type 3 and each different type of form it's going to have a different
set of information inside its payload.
In one case to create a policy the customer might need to provide their name along with some initial
money that they are going to pay to us when they want to create a claim they are going to give us their
name and tell us how much money they want to get.
And then when they want to delete a policy chances are they just need to tell us their name so that
we can go into our big list of people who have policies and just remove them from that list.
OK.
So we have a better idea of forms and departments and this entire flow.
Well it sounds very quickly walked through the process of how each of these different departments would
process each of those different form types.
So in this step right here in the next couple of diagrams things are going to get a little bit more
detailed.
But remember we're going to eventually write out some code to model this entire insurance company.
And so it is important that you understand what is going on internally inside of each of these departments
so that we can actually write some code to model this stuff.
OK.
So let's imagine that our 4 receiver gets a form from a customer and this the purpose of this form is
possibly to create a new claim for receivers are going to take that form and hand it off to the claims
history department whose job is to record a list of all the different claims that have ever been created
when the form receiver hands off that form.
They're also going to get the claims history department.
That list of all the different claims that have been created previously because remember the idea here
now is that we want to have all of our data be centralized inside of this outside data store and only
when a department is given a form are they going to be given their little data set right here and then
it would be up to the claims history department to update that little list of claims history and then
afterwards go and update the claims history list inside of our entire company data so internally the
claims history department is going to take a list of all previous claims in the form and then they're
going to look at the form and they're going to say OK is the form that is coming in trying to create
a claim.
Remember we had said that every department was going to receive a copy of every form.
So that claims history department needs to look at the form type and decide whether or not the form
is trying to create a claim if it's not trying to create a claim.
Chances are this department doesn't care about it they don't care about policies they just care about
claims.
So if this form is not trying to create a claim no then it claims history department is going to say
I don't care.
Just take that list of claims that you just gave us and we're going to return that.
And so we returned the unchanged list of claims and we can kind of imagine that that would be the step
where the list of claims comes out the other end and goes back to our original company repository of
all data now on the other hand if the form that is coming in is trying to create a claim yes then the
claims history department is going to say OK I need to understand who is trying to create this claim.
So it's going to pull off the payload part of that form.
It's going to add that to the list of claims and then it's going to essentially take that list of claims
and dump it out front in order to make sure that it updates the central repository of claims history
data.
All right.
Now let's go through the same process with the accounting department as well.
So with the accounting department we would have our former Sievert say Hey yeah.
So it just dropped off a form right here.
So here is the form.
And by the way here's also our bag with all of our company money inside of it.
So remember this would in theory be the company money that is stored inside of our central repository
right here.
So the accounting department gets the form along with a bag of all of our company's money.
So then that the accounting department is going to look at that form and they're going to see if the
form is a claim.
If it's a claim then the accounting department is going to pull the payload part off that form they're
going to see how much money the company wants or some of the customer wants as part of the claim.
And let's imagine that the customer is saying that they just got into an accident and they claim that
they need $20.
So the accounting department is going to take that $20 out of the bag and send it off to the customer.
And then after that the accounting department will take the rest of the money in the bag which is now
down to 80 because they just took out 20 and they'll return it from their department so that it can
go back to that central repository.
Now that's not the only type of form that the accounting department probably cares about the accounting
department probably also cares about the case in which someone is trying to sign up for a new policy.
So the accounting department is also going to look for forms of type create policy.
If they get one then remember the create policy form is going to contain some amount of money to initially
sign up for a policy.
So we're going to imagine maybe they include $20 to sign up for a new policy here.
So the accounting department is going to take that money and put it into our big bag of money and return
that.
And now our company balance is now at 120 and then in the final case I don't hear if the person or the
form is not trying to create a claim and not trying to create a policy then they can Department is going
to say I don't care just to turn our bag of money with the original hundred dollars and they're going
to throw it out the other side.
All right so just one more step.
So this is the final foreign type or the final department the policies Department.
So again we're going to imagine the Ford receiver takes the form that was just handed to them by a customer.
They're going to hand it to our policies Department along with our list of everyone who holds a policy.
So the policies Department is going to look at that form.
They're going to look at that type on it.
They're going to say OK is this form the type that is trying to create a policy or end a policy if it's
not then they're going to say oh I don't care about this form and they're going to dump out the original
list of people who have a policy completely unchanged.
But if the form is trying to create a policy or end up policy then they're going to say all right are
they trying to end a policy then I'm going to find their name and take it off that list.
Otherwise if they're trying to create a policy then they're going to take the name off the form and
add it to the list and after they produce this new list over here that says everyone who has a policy
just as before are going to say that that new list of people who have policies is going to go back to
this central repository up here.
All right.
So I know that was an incredible amount of detail but that is it for the analogy.
So I think you now understand the entire flow of what is going on inside of our insurance company.
Remember in total we've got the customer who drops off the form.
The form has a type and a payload.
The form receiver going to make a copy that form handed off to each different department along with
each different departments little slice of company data.
Each department is going to look at the foreign type and decide whether or not it has to process the
form.
If they do they're going to make an update to their little slice of data and then eventually return
it out the other end and send it back to this central company repository.
So now that you understand this kind of analogy here we're going to take another quick pause come back
the next section.
I'm going to tell you exactly how this all relates precisely to the world of redux.
All right.
So quick break and I'll see you in just a minute.