Store Refactor (Draft)

[jarmoza]

We're (mostly) done with refactoring individual components. Now we want to find overlap in the getters and mutations that the components expect to access in the store, so that we can reuse these store methods as much as possible. We would like to reuse them so much, that we will consider small refactors of components to allow them to reuse an existing getter/mutation instead of needing a custom one (within reason).

This Epic is a place to track the work and to have some discussion about the overall approach.

• Identify getters and mutations that can be reused across components #243
• Define unique getters and mutations #247
• Define state variables that getters and mutations require #244
• Draft the getters / mutations needed by the file-upload page #245
• Draft the getters / mutations needed by the download page #246
• Understand how to write unit tests for store methods using cypress #250

Codeshare for our original I/O store refactor spec'ing: https://codeshare.io/r9WllY

[jarmoza]

Summary

1. new action alterColumnCategoryRelation
2. former actions changed to mutations linkColumnWithCategory and unlinkColumnFromCategory

Description

The table click functionality of the column-linking-table used to emit click data back up to the categorization page, which would in turn use conditional logic to determine if a column should be linked with a category or unlinked.

This occurred via the actions linkColumnWithCategory and unlinkColumnFromCategory.

// 1. Link or unlink the currently-selected category and the clicked column
if ( this.selectedCategory !== this.columnToCategoryMap[p_row.column] ) {
    this.linkColumnWithCategory({...dataForStore, category: this.selectedCategory});
} else {
    this.unlinkColumnFromCategory(dataForStore);
}

This logic will now be relocated to the store via overarching action alterColumnCategoryRelation that was introduced in #230. linkColumnWithCategory and unlinkColumnFromCategory should now become mutations that directly manipulate the columnToCategoryMap in the store.

[jarmoza]

Summary

1. new store getter columns, a list of objects that contain a column name and column description (empty string if none) parsed from the dataTable and dataDictionary
2. Removal of columns list in the dataTable store field

Description

In order to produce the table rows of the column-linking-table, a function located in the categorization page setupColumnToCategoryTable was run and its return value passed to the column-linking-table as prop.

Instead, the refactored column-linking-table now utilizes a new store getters columns (which parses this information, name and description of each column from the dataTable and dataDictionary store fields). See computed tableRows in column-linking-table for how it is being used (#230).

[jarmoza]

The functions below were removed from the categorization page relating to the categ-tool-group component. Depending on what we end up doing with that component and its functionality, these functions may be need to moved to the store and/or altered.

            removeToolGroup(p_toolGroupData) {

                // Remove this tool group from the store
                this.$store.dispatch("removeToolGroup", p_toolGroupData);
            },

            saveNewToolGroup(p_toolGroupData) {

                // Create this new tool group in the store
                this.$store.dispatch("createToolGroup", p_toolGroupData);
            },

            setSelectedCategory(p_clickData) {

                // Save the name of the selected category
                this.selectedCategory = p_clickData.category;
            },

            toolGroupAction(p_event) {

                // Create, modify, or remove this tool group in the store
                this.$store.dispatch(p_event.action, p_event.data);
            }

[surchs]

Hey @jarmoza and @rmanaem: we have our sketch of the store refactor from the miro board. Now we should implement what's on the board as state variables, mutations, and getters in the store. Ideally we can do this in very small and easy to understand increments, maybe even one mutation/getter/action/variable at a time.

One problem will be (I think) that the end-to-end tests will continue failing until we have successfully stitched everything back together. That's a bit too wobbly for my taste - if a mutation is bugged, we'd ideally catch that right away. One answer is to use unit tests for the store methods (see #250) - and I think we should do that. Another (parallel) idea might be to figure out partial e2e tests that might already work even though the rest of the app is still broken (e.g. getting up to the categorization page, even though annotation is still broken). @jarmoza: any idea how feasible this might be?

Let's collect some thoughts here on:

• how to break up the work on the miro board into (ideally) independent chunks
• how to assure that new / refactored code works, even though the whole app is still broken (testing)

and then discuss