Are We There Yet?

We have a nifty catalog that handles our data operations and keeps copies of the records on the backend, like a cache, if you will. That said, it’s far from finished. Is code ever finished, though? There are loads of things we could add or change to improve it. Here is a list of things we thought of:

• Collections should be hashes, like POJOs, or Maps for quicker look-up.
• Some refactoring would be valuable to have fewer conditional branches based on type. A lot of the methods can only deal with bands and songs and are not prepared for other model types.
• add could return the record just added, or already found, in the catalog
• This is not strictly for the catalog, but we could enhance our model classes with a save method that would call the current update method of the catalog. Instead of writing catalog.update('song', song, attributes), we could write song.save(attributes). This greatly improves developer ergonomics.
• We could add fetch to complement fetchAll. We don’t need to query a single record from the back-end in the current state of the app because by the time we enter the bands.band route we can be sure to have fetched all the band records from the backend, so we can just look up the one we need from the catalog. However, in most applications, the need to fetch a single record is very common.
• Reverse relationships are not automatically updated. If we call catalog.fetchRelated(band, 'songs'), we know that each song’s band relationship should be set to band, but this is not done.
• Similarly, when we save a song to the backend where the band relationship is set, the songs relationship with the band could be updated automatically to include the song.

What about Ember Data?

You might have heard about the standard data library for Ember, Ember Data (ED). It is a mature project, almost as old as Ember.js itself and implements what we have in the catalog service and a whole lot more.

The reason we haven’t started using it right off-the-bat is that we wanted to demonstrate that it’s perfectly possible to build an app without Ember Data. It is a common misconception that you need to use Ember Data with Ember, in part because it comes installed with new Ember projects.

The more complex your app’s data scenarios, the more sense it makes to use ED. Because it’s an “in-house” project and not a third party add-on, it’s quite well maintained and developed, so you might decide to adopt it from the start. Possibly the only drawback of this decision is its size. Removing the package from the project reduced both the compressed and uncompressed vendor build by about 20%, the uncompressed size being reduced by 164kb. This can be substantial in some apps.

The Ember Data team is well aware of the all-or-nothing nature of the project and have launched Project Trim. Its goal is to decompose it to smaller packages that each implement a specific feature set, including models, relationships, etc. so that only the required parts need to be installed.

Since we aren’t currently using the Ember-Data package, let’s go ahead and remove it:

npm uninstall ember-data

Note: We have already deleted the Ember Data, but you can also try the above command in the terminal below.