Changes:
* Introduced a cluster marker to denote multiple points of interest at
the same location
* Seperated out a plain enterprise modal into 2 parts
* A modal called EnterpriseModal for showing a list of enterprises at
the same location
* A box called EnterpriseBox(which by the way is also a technically a
modal) that shows the details of that particular enterprise selected
* If at a location there exists only a single enterprise then only the
box is shown
- Simplify if statements with safe navigation operator
- Simplify order cycle nav check spec
- Rename nav check callback so a comment is not needed and remove unnecessary assignation to $scope
Debounce ensures we don't get a million requests if the up/down buttons are clicked rapidly. The onwheel hack adds some protection against scrolling triggering the quantity up/down. See: https://stackoverflow.com/a/51076231
When loading the page $watchGroup calls the listener function for every
listed line item but with a set variant and null quantity and
max_quantity. There's no point on computing an order change when there
was none.
This saves an empty request on the second most used endpoint of the app,
specially busy when users are placing orders.
The Geo service is used heavily in the /shops page and especially in the search function. If the google maps js library has failed to load it was throwing a lot of fatal errors, so this change ensures the /shops page can at least: a) load, b) show some shops, and c) search for shops by name (but not location)
Fixes an issue where if the js library from maps.googleapis.com failed to load in the <head>, all of our subsequent Angular would completely break.
See: https://github.com/angular-ui/angular-google-maps
Note: `bluebird.js` is a new dependency of `angular-google-maps.js`.
Add paymentMethodsAPI specific mapping function, we had some errors in production with mastercards probably caused by ActiveMerchant not handling the card type correctly
Don't submit the request if the user is part-way through typing something in the date field and the date is (currently) invalid; this results in the date ranges being broken and triggering a query for *all* results (with no date range).
The login modal changes the URL to `#/login` which interfers with our
shop pages. In order to show the right shop page, we need to know which
pages are valid and where we have been before we clicked on Login.