Navigation and state

[jarmoza]

Implementation of navbar for the app as well as a generalizable page state via the Vuex data store and state change functionality in the pages. Specifically, the landing (file upload) and categorization pages have had their data and state integrated. Hooks for the upcoming and annotation and download pages exist as well. Changes from the most recent branch that were made for the annotation mockup have been integrated (for now). Next step buttons and navbar item availability are also integrated with the state of each page.

[surchs]

Thanks a lot @jarmoza for this PR. I think this looks really great. I have read through the different sections and added questions to make sure I understand the structure and also added some discussion points. Let me know what you think.

[surchs]

Thanks for the changes. I think we should finish discussing the way we represent state-variable with the unique flags and make sure this is as intuitive as possible, and otherwise as documented as possible.

Otherwise I think this is all good to go

[surchs]

Yeah, I think this is a really important point, thanks for doing this! My personal opinion here would be to keep things consistent with the bootstrap visual language. They have a way to differentiate "active", "selectable", and "disabled" and while that may not be the most visually clear, it's probably a more common and expected style - and that probably helps with intuitive understandability. So my vote would be for a single navbar where we style the current tab (and disabled tabs) using the bootstrap style.

[surchs]

At the risk of turning this into a JS lesson just for myself, I'd like to understand this better first. The page can have states. If I understand this right, the two possible states are

• STATE_NOCATEGORIES_PAINTED and
• STATE_ATLEASTONE_CATEGORY_PAINTED.

is this not just a boolean thing? I.e. wouldn't it be sufficient if the values for these two keys are either true or false?
I think these are the notes you mentioned:

This object variable stores the list of bit flags representing each state. These are meant to be unique binary numbers (e.g. 1, 2, 4, 8, etc.) with 0 representing 'no state'. Values can either be set plainly via decimal numbers or, if it's helpful to be more explicit, via the bit-shift operator (e.g. '1 << 1', '1 << 2', '1 << 3', '1 << 4

So I guess my questions would be here:

• Why do we need unique flags for the STATE_ATLEASTONE_CATEGORY_PAINTED. If I understand this correctly, possibleStates is not shared between pages.
• If we do need unique flags, why do they have to be numeric? Would it be possible to use strings instead? and if not, we should add detailed comments to explain what each numeric flag means.

I think this is a two-part question.

1. Can we make the state encoding easier via boolean / intuitively understandable keywords?
2. Is this bitwise shift syntax a widely used thing in JS world so that we can expect even a relative novice to be familiar with it.