The Lazy State operator uses $ to read from state. For example:
get($.url)
Some benefits of using $ are:
It is valid JS syntax, so get($.url) will run in plain JS and not freak out any linters/validators
It is like JSON path, which uses $ for root. And JSON path is sort of the model it's based on
It's also a bit like a jquery selector, for people old enough to remember jquery
$ is often used as a special variable in JS, devs are kind of used to it
Problems with $ are:
Yes, the code will compile and even run - but you'll get type errors in native JS. Job code isn't really executable until it's been put through the compiler.
It's really really ugly in template literals because of the double dollar, ie:
get(`resource/${$.data.id}`)
Benefits of using @ are:
@ is a symbol related do addressing generally, which fits nicely with @path.to.state
@ is is not valid JS, helping openfn code stand out as distinct from JS.
It's stronger branding and more distinct than dollar
It plays well with the compiler
Works great in template literals
It's quite easy to explain
We can keep $ as an alias for the short-medium term
But the problems with @ are:
Source editors like VSCode and Monaco (and so Lightning) won't recognise @ and will complain. Yes we can add support in Lightning an extend the syntax, but those using third party tools for local dev will have a worse experience
We've already launched $ and are using it in production code. I don't want to re-write everything and retrain now! On the other hand, it IS still new and flagged as experimental, so maybe there's still time for a dramatic change
I think the bottom line with @ is that it's better branding and basically good for us, but it moves the openfn DSL a step closer to being a distinct formal language, meaning we need to support .ojs files and create OpenFn JavasScript language definitions.
To be honest actually $ is no different - it SHOULD be treated as a different language statement, with linting rules and syntax highlighting associated with it. And $ won't run without compilation anyway.
So maybe introducing @ just forces us to be more honest about our coding language.
However, I don't want to do all that stuff if we're going to throw it away next year in favour of a v3 langauge syntax, as is being discussed in the dark corridors of power here...
The Lazy State operator uses
$to read from state. For example:Some benefits of using
$are:get($.url)will run in plain JS and not freak out any linters/validators$for root. And JSON path is sort of the model it's based on$is often used as a special variable in JS, devs are kind of used to itProblems with
$are:Benefits of using
@are:@is a symbol related do addressing generally, which fits nicely with@path.to.state@is is not valid JS, helping openfn code stand out as distinct from JS.$as an alias for the short-medium termBut the problems with
@are:@and will complain. Yes we can add support in Lightning an extend the syntax, but those using third party tools for local dev will have a worse experience$and are using it in production code. I don't want to re-write everything and retrain now! On the other hand, it IS still new and flagged as experimental, so maybe there's still time for a dramatic changeI think the bottom line with
@is that it's better branding and basically good for us, but it moves the openfn DSL a step closer to being a distinct formal language, meaning we need to support.ojsfiles and createOpenFn JavasScriptlanguage definitions.To be honest actually
$is no different - it SHOULD be treated as a different language statement, with linting rules and syntax highlighting associated with it. And$won't run without compilation anyway.So maybe introducing
@just forces us to be more honest about our coding language.However, I don't want to do all that stuff if we're going to throw it away next year in favour of a v3 langauge syntax, as is being discussed in the dark corridors of power here...