-
Notifications
You must be signed in to change notification settings - Fork 3
Support optional variables #25
Comments
Given we now have #1 with different field types, we need to amend this proposal with a solution for non-text field types (such as radio buttons or select boxes). I think it makes sense to make this change: pub(crate) struct VariableConstraints {
pub(crate) selection: Option<Vec<String>>,
+ pub(crate) required: bool,
+ pub(crate) optional_name: Option<String>,
} In this case, you set a variable as This optional name is what's used in a select box as the top-most option to represent "no value". So for example, if my select box options are:
And I make this variable
Clients can optionally add some styling to make the optional value stand out (grey it out a bit, add an icon to it, or wrap it in dashes such as In the end, optional values together with select boxes aren't great, and you should avoid using them, but an optional value without select boxes is still useful to have. Perhaps it makes sense to start with making the requirement constraint and selection constraint mutually exclusive, as that covers the most common use-case, and also makes it so we don't have to do all the above shenanigans of having an "optional name"? As I'm typing, I'm leaning to; yes, let's make these two mutually exclusive and not deal with the added complexity for now. |
To put the above words into a more concise table:
In other words: if you've provided a If you've defined a |
Currently, all pipeline variables are required to be set before creating a task.
I've come across pipelines that could benefit from optional variables. For example, if your pipeline returns a large set of objects, and you want to allow the person running a pipeline to be able to filter those objects based on some extra variable.
You could add a
{My Attribute Filter}
variable, but now you are always required to provide a filter. You could then use (eventually) step templating (#23) combined with default variable values (#3) to (f.e.) ignore the filter if it's set to the*
value, but that would make steps more complicated to implement and it makes it less clear when using a pipeline what the*
is supposed to mean, requiring you to be more explicit about it in the variable description.So instead, if we allow setting
optional: true
on pipeline variables, they are allowed to be empty. If you use these variables in the steps, a variable that isn't provided simply ends up as an empty string when using the variable (which might still require some templating to use, but I'm not sure there's a way around this).By providing first-class support, we can also automatically convey the fact that this variable is optional in the UI, for example:
The "(optional)" part is added automatically.
Another way to achieve this is to use the default variable value feature (#3), and set the default to an empty string (
""
), which basically results in the same outcome. However, that feels like misusing the system, and it also prevents us from making it more explicit in the UI what is happening, so I'm leaning against that "hack".The text was updated successfully, but these errors were encountered: