Closed CarlosNZ closed 1 year ago
Expression syntax could be something like:
{
fragment: "getCountry",
$country: "New Zealand"
}
Or (probably allow both, like we do with Alias nodes):
{
fragment: "getCountry",
parameters: { $country: "New Zealand" }
}
where getCountry
is a registered fragment in options
:
options : {
data: {...},
functions: {...},
fragments: {
getCountry: {
operator: "GET",
children: [
{
operator: "stringSubstitution",
string: "https://restcountries.com/v3.1/name/%1",
replacements: [
"$country"
]
},
[],
"flag"
],
outputType: "string"
}
}
}
So have "fragment" nodes in addition to "operator" nodes and leaf nodes.
Additional idea (maybe new issue): add a new method to main Evaluator, getFragments
which returns a list of fragments currently stored in options AND a list of the required parameters (will need to do a deep scan of object)
Additional idea (maybe new issue): add a new method to main Evaluator,
getFragments
which returns a list of fragments currently stored in options AND a list of the required parameters (will need to do a deep scan of object)
Probably best to wait until we build a GUI config app before adding this kind of thing.
Fragments would be similar to "Alias Nodes", but registered globally, so don't need to define them in each expression.
The other difference is that they would need to allow "parameters" so they can be called with different values in certain places. This would make providing a handful of "pre-configured" expressions available with just a few variable inputs to make building complex expressions simpler.
For example, this expression might be re-used a lot to fetch a country's flag based on an input code:
The only "variable" is "New Zealand", which we can replace using a local alias "$country"
I think this would actually be quite simple as the resolved alias nodes are already stored in the
config
object. Only difficulty is we don't want them to be resolved yet as they need the inner value first.