-
Notifications
You must be signed in to change notification settings - Fork 58
Fix cart latency #523
Comments
Meeting w/ Casey: STEP 1: Benchmark
Thoughts:
RECORD EVERYTHING METICULOUSLY |
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. |
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:
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:
|
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 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 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 |
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) |
(we should probably try to have this discussion together as a team, to iron out misunderstandings and brainstorm benefits and faults of various solutions)
|
Merging to better organize into #587 |
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:
I think we should consolidate all notes on this problem to a single issue; I'm therefore closing the first three linked issues above.
The text was updated successfully, but these errors were encountered: