Support for more events.

[gavinballard]

Currently, only cart.requestStarted and cart.requestComplete are supported. Want to make this a little better, like cart.itemAdded, cart.itemUpdated, cart.attributeUpdated et cetera.

[stewartknapman]

It would be awesome if the item that was just added to the cart was included in the params given to the event handler.

[gavinballard]

Because it's possible that multiple changes could occur in a single "request" (because cart.requestStarted triggers at the start of queue processing, and cart.requestComplete triggers at the end), I wonder if it would make sense to simply add a cart.updated event that passed a list of changes made to the cart as a parameter. Then you could do something like:

$(document).on('cart.updated', function(changes) {
  // Your code.
});

In the example above, changes would be an object structured like this:

{
  "added": [], // List of items added
  "removed": [], // List of items removed
  "updated": [], // List of items updated
  "attributes": [] // List of changed cart attributes
}

@stewartknapman Do you think this would cover your use case? What would be the ideal way for you to write the code on your end?

The other alternative I've been thinking would be useful would be being able to pass individual callbacks along with each method call, like:

CartJS.addItem(12345678, 3, {
  "size": "XL"
}, {
  "success": function() {
    // success callback
  },
  "error": function() {
    // error callback
  }
});

The latter is pretty trivial to implement and would probably be pretty useful even if there were other means to trigger callbacks, so I'd probably look at doing that first.

[stewartknapman]

@gavinballard Im all for the simplest way first. I think that individual callbacks on core methods like addItem would do the trick at least for providing useful feedback to the user on the product page.

In saying that I havn't got to updating on the cart page yet with this new theme. It will be early next week. But I imagine as a user will only be updating one item at a time this type of callback will be sufficient.

[gavinballard]

The latter part of my suggestion has just been pushed in v0.2.4!

Leaving this issue open as the more advanced changes are probably helpful too.

[bakura10]

That would be awesome to have more events. I need to do specific changes based on specific event but for now the requestCompleted is way too generic.

[gavinballard]

@bakura10, keen to hear your use cases so that I can make sure this feature is the most useful it can be!

[bakura10]

For instance, when I click on a cross to remove an element, I want to trigger a small animation. Actually I realize that this may not work as I want, because I suspect that elements are removed by Rivets. How could I implement that?

[gavinballard]

@bakura10 For this specific use case, it sounds like you might want to have a custom event handler on your cross element to capture the click, perform the animation, and then use Cart.js to remove the item from the cart.

[gavinballard]

Adding a suggested event here: out of stock error.

[bakura10]

Yes, but as a consequence I cannot use the nice "rv-data-remove" things. What I've done is simply initializing CartJS BEFORE my own library. This way, as my listeners are attached last, they are executed first (because you prevent propagation of all listeners). This way I'm able to perform the animation.

[gavinballard]

@bakura10 Okay, great to hear you managed to find a working solution :).

[bakura10]

Well it's not "perfect". I could send you by email the theme I'm working on. It seems that I "hide" the element through animation, but there is a strange effect (like if the list was re-rendered).

[stewartknapman]

@gavinballard does cart.requestComplete know what items have been removed from the cart in the last request? If not, can it? Or would a cart.itemRemoved event be better?

I'm displaying the cart in a side bar on all templates, at all times. This side-cart display is basically just listening to the cart.requestComplete event so that it knows to update.

[gavinballard]

@stewartknapman I'm assuming you're not using Rivets for DOM binding? That's the preferred method for keeping anything more complex than a item count or price total in sync. 

But to answer your question, no it doesn't, although it has access to the cart object. I'm thinking about adding itemsAdded and itemsRemoved events.

On Tue, Jun 30, 2015 at 1:18 AM, Stewart Knapman [email protected] wrote:

@gavinballard does cart.requestComplete know what items have been removed from the cart in the last request? If not, can it? Or would a cart.itemRemoved event be better?

I'm displaying the cart in a side bar on all templates, at all times. This side-cart display is basically just listening to the cart.requestComplete event so that it knows to update.

Reply to this email directly or view it on GitHub: https://github.com/discolabs/cartjs/issues/5#issuecomment-116877189

[stewartknapman]

@gavinballard no, we are doing some crazy things like custom product bundles. Currently the sidebar-cart object knows what items it has so it checks them against what comes back from CartJS and removes any that don't match, but I'd like to be more explicit about what is to be removed from the view.

[gavinballard]

@stewartknapman OK. Then the envisaged itemsAdded and itemsRemoved events should handle your use case.

Another alternative is to just re-render your entire sidebar using the cart object, but not knowing the specifics that could be tricky for you.

[amit0001]

Hey,

It seems like this is what I am looking for to get a callback on: rv-data-cart-update="index | plus 1 " in order to check which product type was added/removed from the cart, and adjust the promotions based on the cart items. Is that correct? Can anyone please suggest a workaround?

Thanks

[gavinballard]

@amit0001 The current workaround for this is to use jQuery's global event handlers, something like this:

// Create event handler for updates.
$(document).ajaxComplete(function(event, jqxhr, settings, thrownError) {
  if(settings.url == "cart/update.js") {
    // Examine the request and response to determine which changes were made.
  }
});

Improving the workflow around this is the top priority for the next release... I'm just pretty time-poor at the moment.

[amit0001]

@gavinballard thanks for the quick reply and offering to help. I tried implementing this workaround, however since all updates are based on line item numbers this didn't really work. Due to the post processing nature of this handler, the cart line items change, before reaching this point, when an item is removed. The removed item is already gone, making it impossible to get the product ID which was removed without terrible sync problems (of diffing what has changed).

I find it strange that there is no way to hook into the rivets mechanism and get a callback when the model changes - I'm just not familiar both with the rivets library or the cartJS library model.

Thanks

[gavinballard]

@amit0001 Thanks for the feedback. There is definitely a "nicer" way to do this, I just haven't quite worked out the best way to implement in the library and haven't had too much time to work on this lately.

For now, I'm afraid the best "solution" would be to avoid using the data-cart-update data attributes and create a custom function that you call directly.

[amit0001]

@gavinballard again thanks for the quick support - appreciate it. So I used the Core API as you suggested and it seems to be working fine. Thanks!

[gavinballard]

@amit0001 Awesome, great to hear! Thanks for your patience. Hopefully we'll have a way to do this that's a lot more developer friendly soon :).