Restructure front-end routing to avoid businessID redirect and hacky navbar

[cjshearer]

Setting the businessID via our current route, where the backend generates some html and js to set a cookie for the businessID, then redirect to the main customer/merchant view is a sub-optimal solution. I believe the best method for handling this would be through dynamic route matching, with vue-router, where the id below could be used by vuex instead of a businessID cookie.

const router = new VueRouter({
  routes: [
    // dynamic segments start with a colon
    { path: '/scan/:id', component: Scan }
  ]
})

An even better approach would combine dynamic route matching with nested routes, where all merchant and customer views will be children of a route that defines the businessID:

const router = new VueRouter({
  routes: [
    { path: '/customer/:businessID', component: Customer, //(a new 'shell' component, like App.vue)
      children: [
        // Scan will be rendered inside App.vue's <router-view>
        // when /customer/:businessID is matched
        { path: '', component: Scan},

        // Cart will be rendered inside App.vue's <router-view>
        // when /customer/:businessID/cart is matched
        { path: 'cart', component: Cart },

        ....
       ]
    },
    { path: '/merchant/:businessID', component: Merchant  //(a new 'shell' component, like App.vue)
      children: [
        // CartVerification will be rendered inside <router-view>
        // when /merchant/:id/cartverification is matched
        { path: '', component: CartVerification}

        // Sales will be rendered inside <router-view>
        // when /merchant/:id/sales is matched
        { path: 'sales', component: Sales}
        ....
       ]
    }

  ]
})

This could also be an opportunity to solve the buggy v-if we use for conditionally rendering a navbar for customer/merchant routes. We could investigate placing the respective navbars in the Customer or Merchant views (the 'shell' components in the above code block).

In summary:

Dynamic route matching is preferable to our current method, as we can:

1. avoid unnecessary redirects
2. avoid setting businessID as a cookie
3. solve buggy v-if for navbar

Why is setting the businessID as a cookie bad? Consider a user visiting two stores that are participating in EZBag. The user visits store 'A', scans their EZBag qr code to open the webapp, and their 'businessID' cookie is set to 'A'. The user may not realize that this qrcode is unique to the store they are shopping at (the user may incorrectly believe that the product barcodes are unique to the store), so upon visiting store 'B', the user simply presses the back button on their browser, and starts scanning products at store 'B'. Either they hit many items that 'don't exist' or worse, the items exist in both stores, and they buy the products from the wrong store. Of course, this could be solved by removing the businessID after checkout, but suppose the user decides not to checkout the items at store 'A' and sometime later goes to store 'B', using the tab still open in there browser. There's just too many ways a user could break this system.