Overhaul cart logic

[austinczarnecki]

There are lots of edge cases that are not covered for the cart.

• dates do not play well with blackout dates sometimes (?)
• button order should not affect who the reservation is for or whether or not the dates register correctly.

[add to this as needed]

Goals: review the logic in detail and possibly look for a library to replace the whole functionality. Would require extensive error-checking to ensure that any new solution plays well with validations etc.

[shippy]

Steps:

1. Replicate (make blackout dates every Sat)
2. Try every possible order of reserving (select reserver / item / dates in cart)
3. See what the problems are
4. Figure out how to fix them

[shippy]

So far, CNR.

Display of 3000 equipment items almost crashes my browser, but doesn't crash the app. This holds for going through equipment_items view as well as through equipment_models view.

Selection: 1. Date Friday-Saturday -> Item -> User works. Will attempt other permutations later.

[austinczarnecki]

Problem is as follows:

The reason that all of the funny stuff is happening, is that once the dates are changed, it takes a few seconds (or longer) for the internal database storing the cart reservations to be rewritten (this should ideally all be handled on the front-end, but was set up this way so that we can run validations right off the bat while the user is in the catalog). While this is taking place, the user is clicking the "Make Reservation" button, and the fine print on the next page shows something other than what was displayed in the cart since rails didn't have enough time to update the backend version of the data.

The simple fix that would solve the issue and allow us to keep the current framework, is to disable the "Make Reservation" button while these behind-the-scenes updates are taking place. I'm looking into how to do this now.

[austinczarnecki]

Looks like disabling the button is easier said than done, will come back to this but at the moment it seems like this type of solution will be really fighting the idioms. Currently considering a custom js template that gets rendered to disable the button when the update_cart method is called, which would then be reversed at the end of the current js template that's called after the database changes are made cart_dates_reload.js.erb.

[squidgetx]

What do we think about just moving the cart logic to the frontend? We'd lose the ability to run validations right off the bat but as it is now it feels like the reservation process is both slow and poorly designed. It's counterintuitive for things to change while the user is updating the cart. Plus, the validations are slow; real time updates aren't worth it if they make everything lag by several seconds. (I mean, then it's not real time). It would be annoying for the user to constantly have to click make reservation to navigate around errors but that's no worse than it is now.

If we want to keep the framework I think we want both a disabling of the make reservation button and also a spinner to indicate that behind the scenes updates are taking place (as mentioned in the short-term fix issue).

Is it possible to pass the user, dates, and items via some frontend method to the confirm reservation screen instead of (I assume) pulling from the database. Validations can be done in the background as the user adds things to the cart/changes things but then when 'make reservation' is hit, don't assume that the database has already been updated and force an update based on the contents of the cart field.

[orenyk]

I don't feel particularly compelled to leave the cart logic in the backend; however, one reason why we do need to hit the server on the date changes is so that we can accurately show item availability counts. It is possible to have a less significant server interaction just to update the catalog view when the two dates are changed and leave out the validations.

In terms of the short term fix, I've implemented both a spinner and disabling all of the cart interaction elements in the issue branch for #528; if anyone could check it out and test it that would be great. Thanks!

[mnquintana]

Merged into #587 #586 #523