Events in Backbone Relational: What are they for, what they do, and can the triggers be safely removed?

2
votes

I have been trying to decipher backbone.relational source code. I found that it fires a lot of its own events. I did a log on some of my models, and found that a lot of these events seem to fire off for no reason.

Big question is which events should I listen to and which are internal events

The events that Backbone.Relational seems to fire are:

  • update:[attribute] seems to fire [Line 725, 941]
  • relational:add This one seems to fire when .add() is called on a collection
  • relational:remove This one seems to fire when .remove() is called on a collection [1651, 1003]
  • relational:reset This one seems to have no rhyme or reason (why is being fired on sort!!!) [1664, 1675]
  • relational:change:[attribute]: Have no idea what this does [1138]

Can someone explain what the purpose of each is and if some of the triggers can be removed from source

For comparison, Backbone's native events:

  • "add" (model, collection, options) — when a model is added to a collection.
  • "remove" (model, collection, options) — when a model is removed from a collection.
  • "reset" (collection, options) — when the collection's entire contents have been replaced.
  • "sort" (collection, options) — when the collection has been re-sorted.
  • "change" (model, options) — when a model's attributes have changed.
  • "change:[attribute]" (model, value, options) — when a specific attribute has been updated.
  • "destroy" (model, collection, options) — when a model is destroyed.
  • "request" (model, xhr, options) — when a model (or collection) has started a request to the server.
  • "sync" (model, resp, options) — when a model (or collection) has been successfully synced with the server.
  • "error" (model, xhr, options) — when a model's save call fails on the server.
  • "invalid" (model, error, options) — when a model's validation fails on the client.
  • "route:[name]" (params) — Fired by the router when a specific route is matched.
  • "route" (router, route, params) — Fired by history (or router) when any route has been matched.
  • "all" — this special event fires for any triggered event, passing the event name as the first argument.
1
backbone.jsbackbone-relational

1 Answers

4
votes

The purposes of each event are quite clearly stated in the Backbone.Relational readme:

  • Bind new events to a Backbone.RelationalModel for:
    • addition to a HasMany relation (bind to add:<key>)
    • removal from a HasMany relation (bind to remove:<key>)
    • reset of a HasMany relation (bind to reset:<key>)
    • changes to the key itself on HasMany and HasOne relations (bind to update:<key>)

As for which events you should listen to: all of them, if you need to. That's why they're there, and documented.

As for which of them are used internally, the answer can be found in the Backbone.Relational source. If you search for .bind in the source file, you'll see that it listens internally to the following events:

  • relational:add
  • relational:remove
  • relational:change:key
  • relational:reset

So I doubt any of the event triggers can be "safely" removed from the source. Generally speaking I would say patching a library source is the wrong way to approach a problem.

You've posted a few questions related to Backbone.Relational events in the past few days. Maybe try to explain why are the events causing problems, and we'll look for a workaround?