In the new API version there is a method using the ... on BoardRelationValue to return the linked item Ids on a board relation column. Extend that to SubtasksValue.
Currently the main way to get the subitem IDs of an item is
items {
subitems {
id
}
}
The subitems subquery is returning items, in this case just the ids are returned. The problem is the subitems subquery is unbounded. It always acts as though 1000 subitems are being returned which skyrockets API complexity. If using items_page this increases it another order of magnitude.
We need ... on SubtasksValue to behave like ... on BoardRelationValue
items {
column_values(ids: "subitems") {
... on SubtasksValue {
linked_item_ids
display_value
}
}
}
Rather than the resolver fetching all of the subitems and then return their values (in this case only the ID) which is complex, this would return only the subitem IDs associated with the item. This would be much lower API complexity since the subitem IDs must be a value for the item already (otherwise how would it resolve the actual subitems for a subitem query?) and would skip the items resolver for all of those IDs.
Then once we have the Ids we can process fetching them ourselves more efficiently - we may need to do more complicated queries on the subitems which are not efficient to nest, esp. with the unbounded size of subitems.
Additional notes:
I am aware I can get them from the value field of SubtasksValue - but that method is becoming potentially obsolete as the API moves to the fragments pattern. I’d like to be able to skip a parsing step as well. (plus save the API servers the requirement to build and serialize the value field when its requested)
lhe linked_items on items has limitations: it requires knowing the board ID and the column ID. Even if you do know the subitems board ID, for the column_id argument on linked_items, the “subitems” column is not recognized. It appears subitems are stored in a separate structure.