Refactor and test missing value component

[surchs]

Missing value component:

• receives currently active category (e.g. "age") via prop (from a parent component)
• receives a filtered view of missing values from the store via getter
• can look up the description of a value in the store via getter (as before)
• informs the store of a change to the missing values via a mutation call to the store

Component test:

• checks that the component likes the data provided to it
• ensures that component actually calls the mutation with the right parameters

closes #212

[jarmoza]

Just a few discussion points, otherwise looks good to merge!

[jarmoza]

Do we want to standardize the field(s) we're using for mock store fields and functions? I'm referring specifically to how getters is defined at the top of this file as a separate field.

[surchs]

Yeah, I was wondering this as well. I think there are some benefits to it:

1. The stuff that can go in the component is prominently displayed up top
2. Because this is a component test file, all tests are going to be for the same component. So we'll probably reuse the data structures in every test (except for minor changes that we can do ad hoc like in this test here)

But this was just the first thing I could think of. I agree it would make sense to be consistent in the future. what do you think?

[jarmoza]

Yeah. Let's just pick something that mimics what we're emulating.

getters, actions (are we doing this?), mutations, props? plugins?

Edit: What about the store? Is it state? (This is even if we just use the getters.)

[surchs]

Agreed. And I think state is a good idea for passing just the store-state object. Should we put that in the wiki?

Did you want to change something about the tests here before merge too?

[surchs]

Agreed. And I think state is good Should we put that in the wiki?
Also: anything you'd like to change here in the test to match that?

[jarmoza]

I think the only remaining question is whether each of the above should be its own variable or if store-related ones (getters, mutations, actions, state) should be wrapped up into a store object.

In this case, like:

const store = {
    getters: { ... }
};

Otherwise, no changes.

[surchs]

Ah, I see. If we do wrap it in a big store object, we'll need to reference them when passing to the mount() directive though, yes? What do you think is the benefit of either you think?

[jarmoza]

Just the mimicry of the actual app internals. For instance, props would not be in the store object. But that's about it.

[surchs]

ah. OK. that makes sense to me!