Currently all array ranges are limited to literal values (from the docs: The range must be a range literal due to parser ambiguity with filters.). My understanding is that the parser does not tell the difference between filtering and slicing so any expression is parsed as a filter. I wonder if this can be solved with a separate pipe function for ranges.
I've ran into this limitation in cases where I want to allow an editor to reference an arbitrary amount of documents. The example below does not work.
{
'display_count': 10,
'articles': *[_type == 'article'][0...^.display_count]
}
A separate function for ranges where there's no ambiguity of parameter count or parameter order (offset, count, inclusive/exclusive) would make this much clearer:
{
'display_count': 10,
'articles': *[_type == 'article'] | range(0 ^.display_count inc)
}
Currently all array ranges are limited to literal values (from the docs:
The range must be a range literal due to parser ambiguity with filters.). My understanding is that the parser does not tell the difference between filtering and slicing so any expression is parsed as a filter. I wonder if this can be solved with a separate pipe function for ranges.I've ran into this limitation in cases where I want to allow an editor to reference an arbitrary amount of documents. The example below does not work.
A separate function for ranges where there's no ambiguity of parameter count or parameter order (offset, count, inclusive/exclusive) would make this much clearer: