Done with a functional manifest resource-path. It's much more verbose, but very explicit and powerful. More importantly, it will be easy to expand as additional search/sort-related functionalities are required.

In fact I can't think of any reason not to do this. The additional code in stripes-connect is only going to be a few line, everything that works now will continue to work exactly the same, and we gain unlimited expressive power for the (presumably rare) cases where we really do need non-trivial logic to assemble our Okapi URL.

I am more inclined to take the nuclear option (which is very much in the spirit of modern JavaScript, and especially React and Redux): allow the manifest's path to be either a template string (as it is now) or a function which returns the string to use. It would look something like this:

And obviously once that functionality was in place, it would be possible to write arbitrarily rich JavaScript code to figure out what URL the available combination of parameters should yield.

We could introduce more fallback syntax into stripes-connect: something like

where the ::- means "substitute nothing at all if the name filter_active is non-empty, and and active=false if it is not. Or maybe a more general ?: operator, like this:

Then we could use it to specify this pair of substitutions:

I think that would do it.

But I am loath to invent new fallback syntax. At least what we have now is based on well-defined precedent in Bash. This would be brand new.

I can almost persuade this to what I want, using the Bash-like substitution fallback syntax in stripes-connect. The problem is that when I use

It substitutes in true (the actual value of the filter_active URL parameter) rather than nothing at all. As a result, I can't just invert the present behaviour as I had hoped.