Okay.
So just to put things into perspective, I've opened up two files side by side.
On the left hand side, I have my job filters, sidebar organizations component where we are currently
storing the users selected organizations in a local piece of data.
And on the right hand side, I have my index file in my stored directory and here is where we have all
of our configuration for the View X Store.
We need to find a way to connect these two pieces or in other words, to get this piece of data to our
View X Store.
Because the View Store is going to need this piece of data which organizations the user has selected
in order to filter the 100 jobs that it's going to get from the backend.
Okay, now here's where things get a little bit tricky.
I'm going to describe the approach we're going to take and I'm going to talk a little bit about its
disadvantages.
What we're going to do in the next couple of lessons is we're going to define a new piece of state to
store this information selected organizations.
So we're basically going to have a very similar property owner of U.S. store state.
Now, the reason this is a bad idea is because it kind of violates the idea of having a single source
of truth.
We're going to duplicate data.
We're going to have this data locally in our component.
And then whenever it updates, we're going to send a message to The View Store that it should update
its own data as well.
So we're going to have two places where we're basically storing copies or duplicates of this data.
Local component, end of York store.
That is not ideal.
However, the reason we wound up with this approach is because local data works really easily and really
well with V model, right?
We use that in the first place because it makes it super simple to configure all our inputs and have
you take care of creating that array.
With all of the currently active selections, we just now need to find a way to do the next step, which
is sending this information to view X.
So while it is a violation, we're going to try to forgive ourselves for now and move forward because
I think it makes sense the most logically, right?
We're going to store data locally and any time it changes, we're just going to alert View X that this
thing has happened.
Ultimately, it'd be great if we perhaps had a global piece of state called selected organizations that
we directly connected this V model to.
And there is a way to do that.
However, it's a little bit more complex and tricky compared to simply connecting a V model to a local
piece of component data.
Right.
This is sort of the beauty of view is how simple it makes the model work with just a piece of local
data.
I want to keep that beauty and simplicity, but in order to keep it, we also need to accommodate the
fact that we need to get this data elsewhere to view X on the right.
And so we're going to need to send this data to our store.
Now, as far as your question, you might say, okay, I understand we need to send this data to the
store, but do we need to save it as part of the store state?
Can't we just, for example, use it in a method like a getter?
And the answer is, I think that's a reasonable approach.
And maybe if we were building this out on our first attempt, I think that would be a totally reasonable
path to take.
However, if I go back to my browser, just to show you remember that our organizations are part of
a larger collection of filters.
We have job types, we have degrees eventually.
And the intent of this web app is the user is going to select checkboxes across all of these different
places, and then we want to accommodate every single filter that the user has selected for that in
order to filter the jobs in the right hand side.
The problem is if we store all of this data locally in each component and even in a method, if we pass
the data up, that data is only going to last as long as that method is running.
So imagine the user does a click for organizations.
We might send the data for that checkbox to view X, but then we need to keep track of that data and
what it is.
As the user selects a job type, as the user selects a degree, as the user D selects a job type, there's
a lot of components that are going to play a role in influencing what jobs we see on the right.
And whenever you have that tangled web of complexity where there's multiple things that are influencing
a final result, I found that the easiest way to handle that is to try to move all that complexity way
up above the components to the view X layer.
That way, all of that filtering logic can live up there, and if you access all the data it needs to
run any kind of filter logic, it can have the selected organizations, it can have the selected job
types, the selection degrees, it has the jobs array that needs to use the filter so it can do all
of that up there, knowing that it has up to date data and it has all the pieces it needs in comparison,
trying to get these components to alert each other and talk to each other.
For example, the job type section saying, hey, the user has selected a job type that they like to
filter by.
Oh, but also, if you remember, the organizations component has these two checkboxes check.
Keeping that kind of communication happening without resorting to simply sending everything to view
X becomes a lot trickier.
So by storing this selected organization's data in View X, we're going to make it a little bit easier
later on for View X to be able to have everything it needs, including additional data later in order
to be able to perform its filtering.
All right.
So with that in mind, I apologize if that's not a perfect explanation, but the short take away right
now is that.
We're going to save this piece of data as a part of the Global View Store State.
So it's going to live in this component for now.
And then we're also going to send a message to the folks to save it to the U.S., to our state.
Later on, we'll see if we can possibly refactor it to eventually remove this local data.
But right now, this is the simplest approach and I hopefully make sense as far as the logical sequence.
So we're going to have three steps that we need to do here.
The first step is going to be to create a new property on our view store to store the user selected
organizations.
The second step is we're going to need to be able to receive the data from this component and overwrite
the store state.
And whenever we're going to mutate the store state, we're going to need to have a mutation method.
So that mutation method is going to get the array of selected organizations from a component that's
going to overwrite the newly created property on our on our View X Store.
And then finally, once we have the state and the mutation set up, we actually have to run the mutation,
commit the mutation in our job filter side of our organization's component, passing in the value of
the current array so that we send the new array of organization strings every time the user clicks a
checkbox.
All right.
So with that said, what I'm going to do is drag this file here to the left.
And I'm going to open up our test file for view and that is found in store index that test that.
Yes.
Here is our test file.
And as a reminder, we have separate sections here for the state, the galleries, the mutations, etc..
So I'm going to follow a TDD approach once again to wire up our new piece of state and eventually our
new mutation as well.
So right here in my state section, I'm going to describe the new property that I'm about to add to
my View Store State.
So this will basically be our property to store these selected organizations.
So this is going to say it's stores organizations.
That the user would like to filter jobs by.
And right here, we're going to follow a very similar protocol to the tests above.
We're going to get our starting state by simply invoking these state function on the right on the left
hand side.
My apologies.
And we're going to expect that on that returned object that that function gives to us, we're going
to see a new property called Selected Organizations, and one view starts up for the first time.
I think it's reasonable to expect that this is going to be an array that is empty.
And once again, the purpose is going to be that whenever the component updates its own state, it'll
send a message to the UX to say, Hey, selected organizations on the UX store, please update yourself
to what I have.
All right.
So we're going to save this and we're going to run our test suite.
It should expectedly fail because that property does not exist.
So right here, NPM run, test, colon, watch.
We should get a failure because that property does not exist.
And there we go.
We can see here we expected it to be an array.
Instead view received undefined, which makes sense because when we access a property that does not
exist, we get undefined.
So in order to make this pass on our view store state, we're going to define our property called the
selected organizations.
And we're going to set it to be.
An empty array.
That's going to be a starting value.
Of course, we're going to update that later.
When we run a mutation, so save that.
It looks like my tests are taking a little bit to run, but here we go.
Everything is passing great.
So now we've wired up a slice of the view store that's going to store the users selected organizations,
just the strings of those companies based on the checkboxes.
And so the very next thing we need to do in the next lesson is to wire up the mutation that's going
to receive that array of strings from the component and overwrite the view store state.