Let's tell them not to do that, than.

(I would have expected ES6 to have a declaration that you can put on a function to assert that it has no side-effects, like one of the many meanings of const in C++.)

Ehhh, people are going to put.... stuff in there. It's going to get out of hand.

Nope. Nine times out of ten, templating will be expressive enough. The main search, sort and filter operation is something that we're likely to do in one place per module. No point in making use the full power of the functional path for everything when we only need it so rarely.

The manifest, in the mean time, is still declarative. The code in the functional path is not doing anything, it's merely declaring a formula. It is a pure function with no side-effects.

I recall that we had discussed this (since it'd be really slick and let us use template strings) and explicitly rejected it in favour of the templatey manifest-with-dynamic-parts approach we've started towards in order to preserve a strong declarative bent and maintain readability in the face of the temptation to front-load a bunch of logic into the manifest.

If we do want to go this way, perhaps we should replace the templating rather than augment it?

Implemented as described here. Should be added to the stripes-connect API document at some point, but that's beyond the scope of this issue – especially, as usual, we are sprinting to the end of a fixed-length period where we need to show functional progress.