Naturally, in most cases you'll want to only have a single representation of any given model on the client-side at a time. However -- there's really <i>no</i> need to do something this (<a href="https://gist.github.com/1393465" rel="nofollow">https://gist.github.com/1393465</a>) fancy to get this behavior.<p>Instead of making a new Ticket with an existing ticket's "id" ... just use the existing ticket. To alter SupportBee's example:<p><pre><code> var ticketView = new SB.Views.TicketView({
model: SB.Tickets.get(ticketId)
});
</code></pre>
prateekdayal responds, elsewhere in this thread:<p><pre><code> > Because the collection could be inside another object.
> Also there would be other places in the app where
> ticket models are being initialized. By defining/having
> to refer to global variables, you are just writing code
> that is harder to maintain.
>
> The identity map approach is more like Rails where in
> a single request, the same SQL does not hit the db again
> and just returns the pre-fetched results. You don't have
> to think about where else you are fetching the same
> records ever.
</code></pre>
Not quite. Being "more like Rails" doesn't always make more sense, when you're talking about a JavaScript application. In this case, you're creating an implicit global list for <i>all</i> Tickets, regardless of collection -- there's nothing that's less "global" about it.<p>The global lookup is simply hidden inside of the extension, and subtly changes the behavior of "new". Now, when I write: "new Ticket(id)", will I get a new Ticket? Maybe, maybe not -- it depends on the id, and whether the client happens to have a cached copy. Clearer patterns for this include:<p><pre><code> Tickets.get(id) || new Ticket;
Tickets.findOrCreate(id);
</code></pre>
... and so on.
This seems like a useful addition. I hope it will gain traction (<i>if</i> the impl is sober, I haven't tried it out yet).<p>My main issue with backbone are the Collection shortcomings (like this one) which require just the kind of boilerplate-workarounds that are so easy to get subtly wrong.<p>Another example would be the lack of infrastructure for nested Collections (e.g. cf. <a href="https://github.com/documentcloud/backbone/issues/483#issuecomment-1595018" rel="nofollow">https://github.com/documentcloud/backbone/issues/483#issueco...</a>).<p>I understand that backbone doesn't want to grow fat in the core. However it would be nice to see a standard library emerge to cover these very common requirements (perhaps call it "ribcage"?).
> One way to avoid the problem is to remember to pass the ticket object from the collection to the model and not instantiate a new one.<p>My initial thought exactly.<p>> However, as your app grows complex, you will not be able to keep a track of all the places where an object with a particular id is being initialized.<p>That's a bit vague. Why not?<p>This seems not much more than trying to standardize a global registry lookup for your models. Why not just make your collection globally accessible, and reference the fetched model with<p><pre><code> $app.tickets.get(id)
?</code></pre>
> This is where the problem starts. You now have two instances of the model for the same ticket id.<p>The problem is your architecture. The simplest solution is to always use a collection cache. The reason you separate views and collections is so that you only have each object in one place, you are killing the separation here by gluing them back together.