Idiomatic way of refreshing the route when deleting from a paged list

Questions Routing
1

Scenario is the following:

  1. We have a list of (Ember-Data) models displayed in a paged list. Paging is implemented using queryParams
  2. Each list row displays a “delete” button
  3. Clicking the “delete” button triggers an action in the controller that calls destroyRecord() on the model

At this point, we want to refresh() the route, since the model is outdated (a new item from the next page should pop up at the end of the list), but Ember cannot detect that on its own (or can it?).

We have identified two ways for doing that:

  • send() a “refresh” action from the controller to the route when the destroyRecord() promise is fulfilled
  • use the ember-route-action addon and implement the action directly in the route

Obviously the second one would not be idiomatic, since it requires the use of an addon.

Is there any other (better) way to do it?

2

I think you should just do someList.removeObject(itemYouDestroyed) after destroyRecord / promise resolves.

3

I fail to understand how that will somehow trigger a server request to get the updated paged model.

Anyway, the problem is not that the item is not deleted from the list (it is), but that a new item (from the next page) is not appended to it.

4

The idiomatic way to do this is to have the Controller send an action up to the Route and the Route action calls this.refresh();.

As you mentioned there are some plugins that can help with this if you so desire.

5

You could then just query the API right after destroyRecord() call in the controller and just set the new model/propertyX value on controller?

Obviously it can than by refreshing the route but it seems to me having explicit store.queryRecord() in controller keeps concerns a bit more separated.

6

I would disagree. Having the route fetch data then the controller queryRecord after delete seems like the concerns are mixing!

I would suggest either you have the Controller handle all data or the Route handle all data. But not mixing both.

Also the idiomatic method is to have the route handle data (the model). It is canonically supported and best practise untill you need to do more then your typical Ember CRUD app. And then look for different patterns like the controller handles all data or smart components/services. These are advanced patterns where the one described from the guides show the use of the route to control things.

If curious the reason there is a seperation between routes and controllers is to facilitate the delayed nature of AJAX so that the route can render a loading and error sub-states while waiting for the model() hook to resolve. The controller that stay there globally simply waits for the route to set its model property. This facilitates an easy and comprehensive data down design. Since the route also handles the URL it is the prime place to fetch resource(s) based on dynamic URL segments. And after you’ve writen all the logic into the route it doesn’t make a lot of sense to reinvent that logic elsewhere when you could have all the data management in one file: the route.

1 Like
7

I agree. Just there are many ways to update the data after some action.