Fix cart latency

[orenyk]

Users have been repeatedly complaining of a lag between the time they enter information into the cart fields and the time the cart information is actually saved (see issues #327, #448, #510, to list a few). This means that if they hit the "Make Reservation" button too quickly then their changes to the default dates / user are not saved and they end up making reservations for the wrong dates or the wrong people (see #483). Other potentially related issues are #274, and #414.

Major goals are:

• reduce / eliminate lag between cart update by user and cart update on backend
• add flash message to notify user that cart has been updated (e.g. Unclear when cart is updated #327)

I think we should consolidate all notes on this problem to a single issue; I'm therefore closing the first three linked issues above.

[orenyk]

Meeting w/ Casey:

STEP 1: Benchmark

• we can use Bullet and MiniProfiler (there are probably others as well)

Thoughts:

1. Separate the client side (JS) from the server side (Ruby) - give the page all the info it needs to work
2. If we can do validations on both client (JS) and server (Ruby) identically that would be great, look for solutions online (research - hard to do and idealistic and we'll probably have to stick with Ruby, but it would be great)
3. If we can find a library that does cart logic for us, we're done :-D. [Maybe use Spree (or addons)] [There must be a JS library for cart logic, not sure about Ruby]
4. We can have a button to check validations as a quick fix, if necessary and if it can be deployed to improve usability before we get a full fix out.

RECORD EVERYTHING METICULOUSLY

[orenyk]

We've updated the interface to indicate that the cart is being updated until the process is finished (see #528), so this should prevent users from trying to change the cart too quickly. We should still try to make the update process faster.

[squidgetx]

Some thoughts:

The reason why it takes so long is because we auto submit the data to validate on the backend: so users are spared the pain of making a reservation only to be greeted with an error that 'xx item is not available on yy date', and having to constantly click around until they come up with a valid reservation.

However, now that #12 has seen some progress, that becomes less of an issue. Since users have more information about when items are available, date-hunting isn't so necessary anymore. What if we removed the auto-validation altogether?

Imagined workflow:

• Users add items to the cart and set the preferred dates of the reservation, and click "make reservation.
• If the reservation is not available for the requested time period, the Calendar View of item availablity #12 calendar can be rendered on the make reservation page. We could do a calendar for each item or a calendar for all items combined. Anyway, armed with this information the user only needs to make 1 change to the cart dates in order to get to a valid reservation
• If the reservation is otherwise invalid, they'll still be greeted with errors on the make reservation page, similar to how it is now. Note that non-date-related errors are somewhat rare and are more indicative of some kind of rule being broken (overdue reservations, too many of the same model, etc.).

This would break the ability to set the date on the cart and then see what items are available in that range in the catalog, but I honestly don't think that many people are using it this way (I feel like the equipment is the focus and not the dates) but I'm open to other's thoughts on this

Steps:

• Remove cart and cart_reservation model (woo hoo!) in addition to autosubmit on cart form
• Fix/Refactor everything that would be broken by this (probably a bunch of stuff)
• Beef up Calendar View of item availablity #12
  • Add date-start and date-end selectors
    • Default positions are the cart start and cart end dates
    • Figure out UX for setting these dates. This is actually really tricky. Ideal solution would be click and drag, and then have the calendar autoscroll if the user hovers near the edge
  • Allow multiple calendars on the same page (as it is now, there is some use of id's)
• restructure the create page to accept these differently-structured parameters, but it would be totally awesome if users could create many reservations with different dates fairly quickly
• Add calendar(s) to the new reservation view
• Restructure catalog cards (I vote for just removing the "X available in Y date range" section all together)

[shippy]

Agreed, except for the "remove Cart model" -- we definitely need the first for its mechanism (it is currently kept serialized in session).

CartReservation model could maybe be removed: we have no way of setting different start/due dates/reservers for different CartReservations within the same cart, so the only relevant piece of info is EquipmentModel.id, an array of which is stored in Cart.items anyway (and we use roundabout methods of getting rid of CartReservations when we're purging the cart).

That said, CartReservation is useful primarily because it inherits ReservationValidations and allows testing validity prior to attempted Reservation creation. We could work around it: on cart form submission, we could call Reservation.new with parameters from Cart for each EquipmentModel that the user is attempting to reserve, then call .valid? on thus created (unsaved) Reservation object.

Even under status quo, however, there seems to be no reason to actually save CartReservations into a database, as opposed to keeping them serialized in session[:cart] -- one user's cart should not affect another user's cart, so keeping the information about who has what in a cart centrally seems unnecessary.

[squidgetx]

Okay, yea fair, I didn't remember that the cart needs to be preserved between page navigations and that an object defined as a model stored in the session is a fine way to do it. Still we should make sure that the cart is never saved to the database.

I favor the workaround method you propose; it seems more direct to me anyway (cart reservation doesn't really extend plain reservation in any useful way outside of the current autosubmit system)

[dgoerger]

(we should probably try to have this discussion together as a team, to iron out misunderstandings and brainstorm benefits and faults of various solutions)

• cart submission also records the date changes. this will still be necessary even if moved to the session, for when changing pages. perhaps it would work to read in this parameter on every page change, but that could get very messy very fast (params from which partial in which form belonging to which controller). removing the validations from any change on the cart is certainly possible, but is probably not the [only] cause of slowness (database calls and checks aren't /that/ slow). we definitely can't 86 the cart model entirely.
• how much of the reservation process is date-hunting?
• re removing pre-create-reservation validation and having a calendar for each item or all items together: we would need to discuss these points with our clients (e.g. Chris). I'm inclined to say it's bad UX to allow adding to cart and then saying "jk not possible but here's when it /is/".
• date availability from Calendar View of item availablity #12 is afaik only on the equipment models show page? how often do patrons click from the catalogue to other pages? I would probably not click through to the show page very often, and would not expect that as the only show of equipment availability. again, I don't think one should be able to add something to the cart if it physically can't become a real reservation, but this should be discussed with our clients.
• I can imagine a workflow in which a patron adds everything they want to the cart, and then on "make reservation" is greeted by applicable non-date errors and a calendar view for each item so that they could select each date range independently and submit a bunch of reservations with potentially different date ranges. However, is this the workflow we want? How often do patrons make multiple reservations for differing dates at the same time? A start/end date selection at the beginning as we have it now has the appeal of intuitive simplicity for the end-user, and means the reservation is probably valid on the patron's first try, resulting in minimal headache, confusion, and frustration.
• we moved the cart from the session to the database two years ago to avoid potentially overloading the session (it has a limited buffer and if I understand it correctly, the session will just start deleting "old" data once it gets full, although that "old" data might still be needed), and also for patrons' privacy: if everything is stored in the session cookie, and the connection is unencrypted, their cart is literally free and clear and visible to the entire world. see Kill CartItems #137 and create CartReservations #186 for why we moved the cart out of the session. I strongly discourage reverting this work.

[squidgetx]

Merging to better organize into #587