Mirage: "Uncaught (in promise)" after GET

Ember Data
1

Hi All,

I’ve created a new Ember project and I’m using Ember Data. I’ve setup Mirage as a “mock server” and created two routes:

/boards – top level /boards/board – nested

My router map looks like this:

Router.map(function() {
   this.route('boards', function() {
    this.route('board', { path: ':board_id' });
  });
});

With Mirage, I’ve setup some routes as follows (note, I’m not sure whether “resource” means that all CRUD operations don’t need to be explicitly defined, or whether I need to define GET, POST, PATCH etc. as needed):

this.resource('boards');
this.resource('boards/:board_id');

I setup a Factory for “board” and then seeded 5 boards in a default scenario. That part worked!

In my boards template I just iterate through each of the boards and display them. I also create a LinkTo to link to the selected board. All of that works. When I navigate to a specific board, its details are displayed. I can see in Chrome that the Mirage GET is being retrieved successfully, BUT after the data returns and the template renders successfully I receive a console error:

Uncaught (in promise) 
Error: Ember Data Request GET /boards/1 returned a 500 Payload (application/json) [object Object] (http://localhost:4200/assets/vendor.js:56672:16)

-- I'm using PODS structure
-- app/pods/boards/board/route.js

import Route from '@ember/routing/route';

export default class BoardsBoardRoute extends Route {
    model( params ) {
        return this.store.findRecord('board', params.board_id);
    }
}

I’m figuring that there is probably something small that I’m not doing right here. I had originally set up all of the findAll and findRecord calls as asynchronous but I changed them to synchronous hoping to solve the problem.

Any help or guidance would be much appreciated,

Dave

2

Hi @djodonnell! On the surface your code looks fine as-is. Maybe we can dig a little deeper :thinking:

(note, I’m not sure whether “resource” means that all CRUD operations don’t need to be explicitly defined, or whether I need to define GET, POST, PATCH etc. as needed)

To get this out of the way so I don’t forget, the former is correct: resource is like shorthand shorthand for defining GET/POST/PATCH/etc so you don’t need to define them separately. That said, I think this is where your problem is. I will try and explain…

When I navigate to a specific board, its details are displayed. I can see in Chrome that the Mirage GET is being retrieved successfully, BUT after the data returns and the template renders successfully I receive a console error

This is the part that is strange to me. It sounds kinda like the background refresh of the findRecord is breaking in mirage. (if you aren’t familiar with the default behavior of findRecord, it will return the record if its already in the store and then fetch it again in the background to update it, hence why you see the detail page render fine but then the refresh breaks). So anyway the problem is that your GET /boards mirage route works fine but the GET /boards/:board_id breaks. Why? It’s due to the way resource works.

In the mirage docs there is an example like this:

// Resource helper usage
this.resource('contacts');

// Shorthands defined
this.get('/contacts');
this.get('/contacts/:id');
this.post('/contacts');
this.patch('/contacts/:id'); // and this.put('/contacts/:id')
this.del('/contacts/:id');

So when you define these two resources:

this.resource('boards');
this.resource('boards/:board_id');

The first one will create

 this.get('/boards');
this.get('/boards/:id');
this.post('/boards');
this.patch('/boards/:id'); // and this.put('/boards/:id')
this.del('/boards/:id');

But then the second will create these (some of which will overwrite what you defined before):

 this.get('/boards/:board_id/');
this.get('/boards/:board_id/:id');
this.post('/boards/:board_id');
this.patch('/boards/:board_id/:id'); // and this.put('/boards/:board_id/:id')
this.del('/boards/:board_id/:id');

Anyway the TLDR is you can just remove the second “resource” from your mirage config, or you could define shorthands for the exact endpoints you want to make double sure your “API” behaves as expected. This was kind of a weird subtle one, especially with the background reload behavior, so sorry if that’s been frustrating!

3

Hi Dan,

Thank you so much. Yes that fixed the problem, and I appreciate your explanation, makes total sense. Looking at it, I got tripped up by changing the more explicit GET declarations to resources.

Thanks again,

Dave

1 Like