Identity Map

Too much (more precisely, too many) of a good song

It gives us a nice, cozy feeling to see how our catalog service handles all back-end operations and serves as storage for the models, bands, and songs. The pieces of our app that are “closer” to the UI don’t have any low-level network plumbing code, and they are, for the most part, quite descriptive of what they accomplish.

However, if we strain our minds somewhat to see if anything is wrong, we might find something. We use the “typed” collections in the catalog to display bands and songs, but we’re somewhat relaxed about adding new records to these collections.

Consider that every time we go to the songs page of a band, we’ll trigger a route’s model hook and call fetchRelated. It will then diligently fetch the related song records from the backend and load them into the catalog. Does it care if those song records are already in the store? Not a bit. We don’t see anything wrong because we display band.songs in the template, which gets set in the freshly returned array of songs. Nevertheless, it’s still wrong to have an ever-growing number of identical song records in the catalog every time we switch to another songs page.

Can the same happen with bands? The bands route is the top-most route we can navigate to in the app currently. When we visit it the first time, all the bands are fetched from the backend and loaded into the catalog in the model hook of the bands route. Given how Ember’s routing works (as you saw in the Nested routes chapter), we can’t re-trigger the model hook.

Again, the fact that we can’t currently make the error evident doesn’t mean we shouldn’t fix it while we still have the whole context loaded into our head. To give you an example of a scenario where the error could be observed, let’s assume we have the following route structure: