Goal of this iteration: Use DS.Store
Alight, so know is the time to use DS.Store
to add even more ember-data awesomeness. First of all let’s change the Dashboard.GitHubDataSource
to extend a DS.Adapter
so it can be used as data source for a DS.Store
. Next: create a store under the Dashboard
namespace, which uses this very adapter:
1 2 3 4 5 6 7 |
|
The goal of this iteration is to use the stores' findQuery
to get all watched repositories for a given user. Therefore I’ve created a basic repository model:
1 2 3 4 5 6 7 |
|
findQuery
on the store will eventually call findQuery
on the adapter, so the next task is to implement it on the Dashboard.GitHubDataSource
.
1 2 3 4 5 6 7 |
|
Alright, everything is set up to be used in the router, so instead of manually creating a Dashboard.GitHubDataSource
and invoking loadWatchedRepositories
on the repositoriesController
, we use the store
instead. The updated root.user
route on the router looks like this:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
|
Roundup
Great, the dashboard is now officially DS.Store
-ified. Booyakasha. Everything is nicely decoupled and in it’s place. One thing that still bothers me though is the adapter: Dashboard.GitHubDataSource.create()
in the Dashboard.Store
definition. At this time of writing I haven’t found an elegant way around this problem. Do you know one?
UPDATE: It will be possible soon to specify a class as adapter
, see commit 8a6e33f which will be available when the relationship-improvements
branch is merged.
The result of this post’s changes are available at tag v0.0.7 (changes). As always, the result is deployed at code418.com/dashboard.