Define state variables that getters and mutations require

[surchs]

Based on #243 and #247 we have a sense of what getters and mutations we need for our components. Now we want to answer the same question we just answered for components, but for getters / mutations:

• what store.state variables do they need to read from and write to. and
• is there any overlap in these variables across getters / mutations

The end result should be a list of store.state variables that we think will have to exist for the getters / mutations to access. We'll probably have to go through a couple of rounds of discussion for this, so we just need a rough draft for now.

Here is a link to a miro board where we should add the variables (it already has the getters / methods).

[surchs]

@jarmoza do you think we have identified all of the state variables that are needed (as far as we can see) for the store methods to be implemented? If no, could you add the remaining ones. If yes, could you close this?

[jarmoza]

@surchs For state variables, here is what we are currently missing:

1. pageOrder (unused)
2. missingValueLabel (can be localized to download page)
3. annotationCount (new, to be discussed for undo feature)
4. toolGroups - I believe this is going away, but we still have yet to discuss how to distinguish grouped tools from other non-tool custom categories

[surchs]

• pageOrder (unused)

Hhm, I could see this just be a getter that reads some to-be-added index attribute in something like the pageData object. But I can also see how a simple array on the state object makes sense - it's not like we will change these things that often.

• missingValueLabel (can be localized to download page)

I actually think this guy has a use independently of the downloadPage because we want to map missing values to some discrete value. So I'm in favour of keeping it as its own state variable.

• annotationCount (new, to be discussed for undo feature)

I think if this is needed by anything (e.g. the isThisPageAccessible getter, then the functionality should be implemented as a getter.

• toolGroups - I believe this is going away, but we still have yet to discuss how to distinguish grouped tools from other non-tool custom categories

This one is a bit tricky. We want the functionality of "I can add a tool group" but I think the plan was to have this integrated into the regular "add new categories" workflow. I am not sure if we should try to get this refactor done at the same time as fixing this whole store refactor thing.

[jarmoza]

@surchs

• pageOrder - Agreed. Let's move this inside pageData
• missingValueLabel - If we intend to store the original data dictionary for the sake of undo functionality, maybe it makes sense to move this inside of a structure like we had in the past? i.e.

dataDictionary: {
    original: {},
    annotated: {},
    missingValueLabel: "missing value"
}

• annotationCount - 👍
• toolGroups - 👍 We will revisit

[surchs]

OK great. @jarmoza would you mind updating this on the miro board and then closing this issue?

missingValueLabel - If we intend to store the original data dictionary for the sake of undo functionality, maybe it makes sense to move this inside of a structure like we had in the past? i.e.

Oh yeah, good point, we probably want to have this annotated and original in the same object. For the missingValueLabel: what do you think about having a appSetting object or something like that. In it we could store the colormaps and then also this missingValueLabel, and maybe also the pageData? Not a strong preference, but if I look inside the dataDictionary and find this missingValueLabel, then I'm a bit confused.

toolGroups - +1 We will revisit

Nice. Can you link an issue for this here and then we can close.

[jarmoza]

pageOrder - Moved into pageData on Miro.

what do you think about having a appSetting object or something like that. In it we could store the colormaps and then also this missingValueLabel, and maybe also the pageData?

I like this a lot actually. appSetting added to the Miro board.

[jarmoza]

toolGroups - +1 We will revisit
Nice. Can you link an issue for this here and then we can close.

An issue to revisit the tool grouping code has been added here.