Svelte: Alternate helper syntax to allow fixed additional parameters like `computed`

[lnryan]

While I understand the _intent_ of helpers as immutable functions to be useful, I'm finding it pretty inconvenient not to be able to access any other elements in my data. Particularly in SVG the number of consistent "extra" parameters needed can get pretty large and this can lead to errors.

For example, if I want to provide a helper that skews any SVG element in the same way, say scale + rotate, right now i need to call a helper like this

skewer(x,y,scale,rotate) but I actually don't want my html portion to be able to get scale,rotate wrong. I want to lock these down by only calling skewer(x,y).

without the immutability constraint, I'd simply have

function skewer(x,y){
    var r = this.get('rotate');
    var s = this.get('scale');
    ...then my algorithms to scale and rotate x,y using r,s...
}

I think extending helpers with a concept like computed where the 'extra' data/computed bindings are specified could be a good compromise between the intended immutability (and compile-time analysis) of helpers and the supply-only-what's-actually-variable ideal.

I can think of two ways: a. computed-like lambda returning a function; b. an optional object-notation with function + using section

helpers:{
    skewer:(fixed_param1,fixed_param2)=>{
        return (variable_param1,...)=>{
            ...my logic using f1, f2, v1, etc
        }
    }
}

or

helpers:{
    skewer:{
        fn:(variable_param1){...},
        uses:[fixed_param1,fixed_param2]
    }
}

What do you think?

[Conduitry]

It's possible to have computed properties whose values are themselves functions. Would that be another way to achieve what you're looking for?

edit: This is very similar to your first suggestion - except skewer would be under computed. It would depend on fixed_param1 and fixed_param2, and its value would be a pure function of variable_param1 etc.

[lnryan]

Maybe - i'll try that out...so i can have a computed property that i call inside a tag as basically computed(x,y). question would be, would this reliable re-execute when x,y change?

[Conduitry]

Yep, see this REPL example. Updating either a or b causes the value to be updated.

[Rich-Harris]

We should probably add an example/line in the docs about this. I do it a lot with e.g. scales that map a domain to a range, and it's extremely handy

[lnryan]

when i finish mine i can also tidy it up into an example if it's liked as such. should we close this then?

[arxpoetica]

@lnryan Let's leave it open as a reminder to add documentation. If you want to add an example REPL, that could help toward that end.

[Conduitry]

Closing this, since the guide now mentions that computed values can be pure functions.