QueryBuilder Feasibility - Between/In/NotIn Operators

[keerthankrishna]

When using the between operator, does QueryBuilder allow displaying 2 textboxes where User can input any value rather than using a comma separated single input textbox ?

Example:

1. I select a Date field.. and expect 2 calendar dropdowns to show up when I select "between" operator
2. I select a Cost field.. and expect 2 textboxes to show up when I select "between" operator

Right now, it just shows one textbox and expects the User to put comma separated values

[jakeboone02]

I've actually been thinking about this for a while now. You can always use a custom ValueEditor component to display whatever you need, but as far as default functionality, no, "between"/"notBetween" (and "in"/"notIn" for that matter) do not display two (or more) inputs.

There are two things holding me up: 1) it would be a breaking change and I'm reluctant to do that especially so soon after releasing v5, and 2) I'm not sure what a good default setup would be and how configurable it should be.

There are a lot of questions even if we just try to tackle the "between" case. Should there be a configurable element between the two inputs? Maybe the word "and" (so the rule would read "FieldName between X and Y")? Should it be a full-blown component or just a string from the translations prop? Should it default to hidden or visible? Is the listsAsArrays prop enough to manage the way the handleOnChange prop is called from within the default component?

If we take it further and handle the "in" case, then we're dealing with a dynamic number of inputs and not just a fixed set of two. Same questions about a string or component separator (this one should probably default to ","), but we would also need to think about new components for managing the addition and removal of inputs. There's not really a good, subtle way to represent a "delete this input" mechanism using native HTML form elements, so we might have to style something which I don't want to do (this library purposefully has minimal default styling).

All that said, maybe the "in" case can be ignored for now. But if I do add double-input default behavior for "between" I want to do it the right way.

[jakeboone02]

See #428.

[keerthankrishna]

You are right - Only the "between" would need 2 input fields and not the others (in, notin)
"in" and "notin" can actually use comma separated values. More thought process would need to go into the change needed for "in" and "notin" if at all a change is needed.

Thank you so much for putting in #428 for "between" and "not "between" operators!