Repository navigation
Ability to access reverse relations within entry query in GQL #7110
Description
It would be really useful if when querying entries in GraphQL you could get reverse related elements to that entry, which would avoid you having to do multiple GraphQL calls of "get the entry ID, and then run another GraphQL query with relatedTo() because this can quickly add up and become clunky.
Original comment from other thread
Just a thought, and apologies if this was covered in other thoughts above and I misunderstood, would a good syntax for this be something like relatedEntries, relatedAssets etc. which behave like a normal entries / asset loop but with the relatedTo pre-populated with the current entry. So you could do things like this very weird, but hopefully useful example...?
entry(section:"offices",slug:"london"){
title,
id,
... on offices_offices_entry {
peopleInThisOffice: relatedEntries(section:"people"){
title
}
facilitiesInThisOffice: relatedEntries(section:"facilities"){
title
}
imagesTaggedInThisOffice: relatedAssets(source:"images"){
title
}
}
}
Originally posted by @andrewfairlie in #5143 (comment)
Reacted by James Edmonston and Nikolaj Selvik
Activity
Add argument manager and argument handlers.
andris-sevcenko commentedon Nov 27, 2020
This has been added for Craft 3.6
andris-sevcenko commentedon Nov 27, 2020
Well, in its own branch for now.
Merge pull request #7202 from craftcms/feature/graphql-relation-argum…
brandonkelly commentedon Dec 2, 2020
Merged now. Note that it’s
relatedToEntries, etc., notrelatedEntries.brandonkelly commentedon Dec 15, 2020
Craft 3.6 RC2 is out now with these new GraphQL arguments.
brandonkelly commentedon Jan 27, 2021
Craft 3.6 has now been officially released ✨
membla commentedon Feb 22, 2021
Just had a conversation on Discord with @andris-sevcenko on this – the actual issue at hand here is not resolved and even if it may not be feasible to do it in the GraphQL API without changes to the Element Query API or Element itself I think the issue should be reopened because the use case is very valid (and well explained in the original post above).
brandonkelly commentedon Feb 23, 2021
Whoops, you’re right @membla. Guess we were on a different brainwave. We’re considering how to best address this.