How to get meta from after saving model?


#1

My server adds meta data to JSON-API response as described in specs. And I try to get it in Ember:

let event = this.get('store').createRecord('event', attr);
event.save()
    .then((e) => {
        console.log(e.get('meta'));
        doSomething(e);
    }).catch((error) => {
        event.deleteRecord();
        handleError(error);
    });

But it returns undefined. I found addon https://github.com/ef4/ember-resource-metadata It stores meta-data to WeakMap in service for each model. Is it good solution? Maybe there is native Ember approach?


#2

In my experience, ember-data doesn’t treat the meta property as a first class citizen. I believe you have access to it during the deserialization step, but that’s it. The addon you listed is the way to go. @ef4 may have more accurate thoughts to share though.


#3

The spec allows meta in a lot of different positions.

  1. Top-level: this is partially supported by ember-data itself. For example, the object that comes back from store.query() and the list of related models in a hasMany relationship will have a meta property that comes from the request that fetched them.

  2. Resource-level: the ember-resource-metadata addon is specifically for resource-level meta, meaning this one:

    {
      data: {
        type: 'things',
        id: 1,
        attributes: {},
        meta: { thisOne: 'yes' }
      }
    }
    

    Keep in mind there can be many different resource-level metas in a single response (because you could be fetching a whole collection, and because the included resources can also have their own metas.

  3. On resource identifiers, like:

    relationships: { 
      owner: { 
        data: { 
          type: 'users', 
          id: 1, 
          meta: { ohYesItCanGoHere: true }
         }
        } 
      }
    

    In this case it’s about the object you’re linking to.

  4. On relationship objects, like:

    relationships: { 
      owner: { 
        data: { 
          type: 'users', 
          id: 1, 
         },
        meta: { ohYesItCanGoHereToo: true }
        } 
      }
    

    In this case it’s about the relationship, not the target of the relationship.

  5. On links objects. links can occur in multiple different places, including the top-level and inside relationship objects.

    relationships: {
      owner: {
        links: {
           self: {
             href: 'http://example.com/people/1',
             meta: { yupItCanGoHereToo: true }
           }
        }
      }
    
    

Ember Data doesn’t have API for most of these. The basic user-facing concepts in Ember Data were all created before JSON:API was codified.

The next step toward adding this capability is probably collaborating on an RFC that shows what the user-facing API for these should look like.

Right now, the practical way to get access to any of these – using entirely public API, so no risk of breaking in the future – is to extend your own adapter and/or serializer that just watches the documents going by and reads the meta. If you look at how ember-resource-metadata is implemented, it shows how you can use the same pattern to see anything about any server response.


#4

Hi, Thank your reply. I need meta in resource-level and I started to use your addon.


#5

I’ll assume the role of the CTO (Chief Tagging Officer) and gently ask people to tag their questions with the “Questions” tag (category).

Now that we (as in, the Ember community at large) seem to have some agreement that asking questions here (as opposed to on slack) is quite useful and start to have some questions coming in, it helps people ready to ask questions to do that by simply going to the Questions category (or seeing them at a glance).

@dimas09 Could you do that for this question?


#6

@balint Is it not possible for mods to add the tag? I think in SO this is possible


#7

Do you mean for the forum admins? I’m sure they can do it but I’m not sure how much they monitor this forum and if people apply the tags right off the bat, they might also get answers more quickly (because of improved discoverability).