[Fix Cart Latency] Design specs for newly architected cart functionality

[squidgetx]

PROPOSED WORKFLOW

• CartReservations is no longer a thing
• Cart no longer autosubmits info for validation (or only validates for dates?)
• "Check availability" button exists to refresh catalog (?) and to set flash notice if items are not available for new dates
• Reservation 'new' view (finalize reservation view) shows calendar availability of items (if items are not available for submitted dates)

[squidgetx]

New Cart Model

• start_date
• due_date
• reserver_id
• Hash of equipment models and their quantities: the EM's are the keys and the values are the quantities. This will make it very easy to draft an 'available?' declaration

require 'spec_helper'

describe Cart do

  context "General validations" do
    it { should validate_presence_of(:reserver_id) }
    it { should validate_presence_of(:start_date) }
    it { should validate_presence_of(:due_date) }
    it "should validate that start date is < due date"
  end

  describe ".initialize" do
    it "has no items"
    it "starts today "
    it "is due tomorrow"
    it "has no reserver"
  end

  describe "Item handling" do
    describe ".add_item" do
      it "adds an item to the array"
    end

    describe ".remove_item" do
      it "removes an item from array"
    end
  end

  describe ".empty?" do
    it "is true when there are no items in cart"
    it "is false when there are some items in cart"
  end

  describe ".prepare_all" do
    it "returns an array of reservations"
    describe "reservations in array returned" do
      it "inherits the cart start date"
      it "inherits the cart end date"
      it "inherits the cart reserver"
      it "inherits the cart items"
    end
  end

  describe ".purge_all" do
    it "empties the cart"
  end

  describe ".models_with_quantities" do
    it "returns a hash of models as keys and quantities as values"
    #do we really need this?
  end

  describe ".check_availability" do
    context "items are good to go" do
      it "sets the flash to success"
    end
    context "items are not good to go" do
      it "sets the flash to detailed error message"
    end
  end
end

[squidgetx]

Current workflow for adding an item to the cart

• Add to Cart button sends a PUT request to /add_to_cart/:id
• /add_to_cart/:id is a custom route that goes to catalog#add_to_cart
• catalog#add_to_cart calls catalog#change_cart(:add_to_cart, :equipment_model)
• which finally calls cart.send(:add_to_cart, :equipment_model)
• validateSet is called on the cart
• A redirect to the root path is called
• A render js action is called on "update_cart"
• Div list_items_in_cart is refreshed with $('#list_items_in_cart').replaceWith('<%= escape_javascript(render :partial => 'reservations/list_items_in_cart') %>');
• Flashes are cleared/reset in a similar manner

---

Proposed Changes

• Obviously, don't call validateSet
• Use pure jQuery or other frontend to update the list items div instead of using a render partial. This should reduce the server load, though it's unclear how it would fit in easily in the current workflow

removing is similar

[squidgetx]

Useful links, perhaps

• CookieSession, as an alternative to the db session we are using currently
• RailsCast on ajax/javascript forms
• Gon Gem - Passing lots of data easily from controller to js. Potentially useful for running validations clientside and/or optimizing Calendar View of item availablity #12

[shippy]

Note of caution: the only thing that ReservationsController#create takes from in-database CartReservations is equipment-model IDs. It takes start date and due date from params[:reservation], which is a hidden field on the submission page. As this is expected behavior in the refactoring, I just wanted to document it here.

[squidgetx]

What if we simply split up the validations between the fields that they're relevant to?

• When a user changes a date, it autovalidates only for availability and blackout dates.
• When a user adds/removes an item to the cart, it validates for max-model count.

If we remove cart reservations and write custom methods to check these validations (that take arrays of equipment model id's or something as arguments instead of reservation objects) I think it has a chance at being fast enough.