UI should always reflect internal annotation state

[surchs]

As a user, after I have annotated a column (and saved the annotation), whenever I navigate back to the annotation page (i.e. navigate away and go back), I want to see the stored annotations in the user interface, so that I can easily change any of them and don't have to redo all annotations if I just want to change one.

Tests:

• if I annotate a category and "save", then navigate to a different annotation tab and return to the category tab, I can still see the values I have just annotated in the User interface.
• if I annotate a category and "save", then navigate to a different page and then return to the annotation page and category tab, I can still see the values I have just annotated in the User interface.

Background:
At the moment, free form input fields on the annotation page are not two-way linked to the internal state. That is, I can provide a new annotation value in the field, but when I navigate away and come back, the text field will be empty / in it's default state, even though an annotated value exists in the internal state.

This is because at the moment we are treating the input fields like buttons and listen to their @change or @input events, rather than using the v-model directive as designed.

There is a bit of work involved to get v-model to work (hence why it doesn't work yet), because we will have to use scoped slots in order to handle each value individually. We should write up the work that needs to happen and then implement so that a user will always see the internal annotation state when they look at the annotation interface!

[jarmoza]

Just noting - Began this task yesterday.

[surchs]

This is blocked by #199 because there is no direct way to know the current mapping of a unique value.

[jarmoza]

*Other than to find the raw value in the original data table

[github-actions]

We want to keep our issues up to date and active. This issue hasn't seen any activity in the last 30 days.
We have applied the stale-issue label to indicate that this issue should be reviewed again and then either prioritized or closed.

[surchs]

This is a tricky one. In a way this is dealt with via everything in #251, and it's also blocked by that. So we can keep it open, but it'll just be addressed by redoing the whole store and data flow via #251 - I'd also be OK with closing it and tracking the work over there.

Any thoughts @jarmoza?

[jarmoza]

@surchs Let's close this and move discussion/work over to #251. I'll link this issue so your text above remains surfaced.