You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The property name must be a static string (no reference, why would you declare a dynamic key? How would you read it back out again?). I suppose it could take a JSON path (in which case it has to start with $ I think?):
declare('$.results.patients', [])
The value could be a reference function. This would allow you to generate complex derived values for your state keys. It takes state as an argument and the returned value will be written to state.
Pros:
It's offers a slightly more declarative, readable, intentional style than fn
And actually it's much more terse too, without the faff of the nested arrow function and return statement
It's cheap and easy to add and no-one will be upset if it's not used
It would be quite nice in a visual job builder
Cons:
You don't technically need it in v2, you can just do const x = 10 at the top of your job code (but only at the top!).
You can only declare one thing at once
Does it confuse things with fn() if the value is a function? When do you use fn and when do you use declare? I don't really think this is a problem though.
The text was updated successfully, but these errors were encountered:
I wonder if declare could take a function, and that function can be serialised to state for re-use in later jobs (see OpenFn/kit#648)
Like if the value is a function, maybe declare can do something to make it serialiisable. Obviously the runtime would need to deserialise it in the next job.
We often use an
fn
block to declare variables on state:We could introduce a
declare
operation, the sole purpose of which is to write a property to state:This would be useful in https://github.com/OpenFn/water-aid/pull/31/files
The property name must be a static string (no reference, why would you declare a dynamic key? How would you read it back out again?). I suppose it could take a JSON path (in which case it has to start with $ I think?):
The value could be a reference function. This would allow you to generate complex derived values for your state keys. It takes state as an argument and the returned value will be written to state.
Pros:
Cons:
const x = 10
at the top of your job code (but only at the top!).fn()
if the value is a function? When do you usefn
and when do you usedeclare
? I don't really think this is a problem though.The text was updated successfully, but these errors were encountered: