Relationships are not serialized by default?

[pichfl]

Is there a reason alwaysIncludeLinkageData isn't true by default? There is no way to reach the relationship from ember if not even the ids are serialized.

import { JSONAPISerializer } from 'ember-cli-mirage';

export default JSONAPISerializer.extend({
  alwaysIncludeLinkageData: true
});

[mansona]

I've just hit this same issue 🙈 I lost a few hours trying to figure out why my definition of the relationships in the "backend" of mirage was incorrect

It is my understanding that this behaviour makes the default JSON:API serialiser invalid 🤔 the content that the backend returns for a given entity shouldn't change based on the includes query param, only the contents of the JSON:API includes array

Would it be ok for me to submit a PR to flip this default?

[samselikoff]

Yep, sounds good! I guess this would be a minor bump on miragejs and a major for ember-cli-mirage.

[mansona]

so... there is a potential way to do it in the mean time if you were against a major bump 🤔 you could just fix the default blueprint to make it a part of the serialiser it generates?

you could also create a deprecation in the case that the user-land serialiser doesn't have the parameter defined, but that really depends on how much you care about wanting to not do a major bump 😂 thoughts? (I'm happy to do the extra work to fix the blueprint and make a deprecation if you think it's worth it?)

[samselikoff]

I don’t really care about a major bump! Cared for way too long lol

[zeppelin]

@samselikoff @mansona When I turned this on in the app serializer, it broke my tests. I'lll investigate further, but regardless the results (my setup is pretty basic), it's likely that some other apps would end up the same.

[samselikoff]

I'm actually not sure re: the spirit of the spec. I think Resource Identifier Objects are really intended to be used to cross-reference resources that are being included in a compound document. Might be worth checking in with @dgeb before we change this behavior.

[dgeb]

I think Resource Identifier Objects are really intended to be used to cross-reference resources that are being included in a compound document.

While identifier objects may be included to indicate member(s) of a relationship, @samselikoff is right that their primary purpose is to provide linkage in a compound document.

Consider a has-many relationship that includes thousands of members: including a full set of those members can sometimes be unrealistic, while including a partial set can be confusing since you'll need to reference relationship links to understand that it's a partial set.

I think a sensible default is to always include links for relationships and, if related members are needed, include linkage data as well when requested via include.