This PR implements the nested relationship fetching described in #11. The related config option now accepts an object within which a property of the Model in question may be used as a key, and its value is another object whose key/value pairs are type: 'property' format. This informs which nested relationships should be requested using dot notation in the request to the API, like so:
/posts/1?include=author.roles
To-Do:
[ ] Limit depth of nested relationships.
A strategy must be implemented to ensure we don’t ever fall into an infinite loop. One such strategy is described in the issue comments, but I’m open to ideas.
[ ] Add comprehensive tests.
I implemented this with a single happy-path test. Additional tests (and, probably, work) is needed to ensure this feature can handle mixed relationship definitions (e.g. an array of objects and strings at the root of the related config key), supplying a Boolean or an Array of properties as the value for the nested type key (e.g. { related: { author: { person: true } } } and { related: { author: { person: [ 'roles', 'birthplace' ] } } }), and thoroughly testing the nested relationship limit described in the to-do item above.
[x] Switch base back to master.
Since this branch is based on the branch for #13, I’ve set the base for this PR to that branch. Once that PR is merged, this should be switched back to master.
This PR implements the nested relationship fetching described in #11. The
relatedconfig option now accepts an object within which a property of theModelin question may be used as a key, and its value is another object whose key/value pairs aretype: 'property'format. This informs which nested relationships should be requested using dot notation in the request to the API, like so:To-Do:
A strategy must be implemented to ensure we don’t ever fall into an infinite loop. One such strategy is described in the issue comments, but I’m open to ideas.
I implemented this with a single happy-path test. Additional tests (and, probably, work) is needed to ensure this feature can handle mixed relationship definitions (e.g. an array of objects and strings at the root of the
relatedconfig key), supplying a Boolean or an Array of properties as the value for the nestedtypekey (e.g.{ related: { author: { person: true } } }and{ related: { author: { person: [ 'roles', 'birthplace' ] } } }), and thoroughly testing the nested relationship limit described in the to-do item above.master.Since this branch is based on the branch for #13, I’ve set the base for this PR to that branch. Once that PR is merged, this should be switched back to
master.