Flexibility and UX enhancement for spec:inputs:rules : allow lint to pass with no default case for non-string conditional inputs

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

• Close this issue

Summary

Allow spec:input:rules without a fallback case to be parsed correctly with a non-string datatype.

That will prevent mutually-exclusive pipeline inputs from appearing at the same time in the UI, which is confusing for the UX.

Proposal

Let's enable a cool UX feature, which is that mutually-exclusive inputs are not all shown together and don't clutter the UI, enabling end-users to select their pipeline inputs more efficiently.

That feature relies on conditional inputs WITHOUT a default rule / fallback case : the input conditionnally disappears from the UI, which was originally not an intended feature, but is great for simplicity and readability in terms of UX.

Currently this is possible only with string-typed conditional inputs, because conditional inputs without a fallback case have their value (null) replaced by "", which is string typed. For other input datatypes (boolean or array), the linter fails because the interpreted value is a string.

I have built ➡️a full example with context in this project ⬅️ , explaining what we can achieve using conditional inputs that way, and how any of the following solutions is a quick win for UX and conditional input feature enhancement.

Try it out and let me know what you think !

1. Stop replacing null input values as "" AND allow null as a valid input for any datatype at the pipeline level.

OR

2. Create default typed nullable values to replace null. Eg null array replaced by [] and null boolean replaced by false, instead of "".

References

This topic was first addressed in this side discussion.

Attainable results

With 5 inputs in 3 mutually-exclusive use-cases, I don't need to show unnecessary inputs at all times.
NOTE : I actually have 5 use-cases and more than 15 inputs, and I am very happy to not clutter the UI and confuse my users with unrelated inputs to their use-case when they have to select what the pipeline has to do.
It allows me to provide them with a "pipeline as a service".

Use case 1 :

Use case 2 :

Use case 3a :

Use case 3b :