I’ve put a lot of thought into this concept and tried a number of different things. For me, I’m using the ‘name’ attribute instead of a slug, but I believe the same rules apply.
I think I finally have a pattern that I can live with, but there were a few “gotchas”, such as:
- Replacing
this.store.find('thing', params.thing_id)
withthis.store.find('thing', { name: params.thing_name })
has at least three consequences:- it will always query the server,
- it will expect an array (e.g. {“things”: […]}) from the server,
- it will return a DS.PromiseArray
Things I tried but decided against:
- Setting the primaryKey to ‘name’ on my adapters, even though my server uses ids (this messed up my belongsTo relationships among other things.)
- Coercing my server-side code to accept
api/thing/kitty
instead ofapi/thing?name=kitty
. I decided that I should tinker as little as possible with my server side and look for the Ember solution. - Using transitionTo to cheat my router and turn thing/6 into thing/kitty. (Need to be able to load the app fresh at thing/kitty)
- Building elaborate beforeModel hooks to pre-fetch models from the store (ie server) and fish the ids out of them so my model hooks can use the ol’
this.store.find('thing', 6)
After learning more about Ember’s Promises, specifically DS.PromiseArray, I settled into just doing this a bunch:
https://github.com/ballPointPenguin/cupery/blob/master/ember/app/routes/description.js
which seems good, but it still hits the server every time.
check out https://github.com/ballPointPenguin/cupery/tree/master/ember/app, which is very much a work-in-progress and changing very quickly, but might be helpful.