IgniteUI / igniteui-angular

Ignite UI for Angular is a complete library of Angular-native, Material-based Angular UI components with the fastest grids and charts, Pivot Grid, Dock Manager, Hierarchical Grid, and more.
https://www.infragistics.com/products/ignite-ui-angular
Other
572 stars 161 forks source link

Query Builder: disabled inputs should be empty #14888

Open imincheva opened 1 month ago

imincheva commented 1 month ago

Issue

image

Steps to reproduce

  1. Start with an empty query.
  2. Create a new group by clicking and/or group button
  3. Select ID column
  4. Select filter, which supports value, e.g. contains
  5. Type in value e.g. 123
  6. Change the selected filter to filter, which doesn't support value, e.g. Empty

Result The "Value" input text still says 123.

Expected result The input text from "Value" input should be removed and the input should be empty.

Originally posted by @imincheva in https://github.com/IgniteUI/igniteui-angular/issues/14647#issuecomment-2396350789

teodosiah commented 2 weeks ago

@sdimchevski Currently, the search value input is not cleared not only if we change the filter from binary ('equals') to unary, but also to another binary ('greater than'). Something that concerns me is that if we clear the search value only for the unary operator, the behavior would be inconsistent. For example, changing the operator from binary to binary would not clear the input, but changing it to unary will. Another thing is that if we set the operator to binary again, the search value would not be restored. Having these in mind, wouldn't it be better if we either clear the input in all cases (for unary and binary operators) or keep the current behavior? Also, if we decide to clear it, should we restore the previous value if the operator is changed back from unary to binary?

sdimchevski commented 2 weeks ago

@teodosiah from a consistency standpoint, users will quickly understand that changing the operator will always reset the input, making the component more predictable. Since consistency and predictability are our top priorities, clearing the input value in all cases (whether for unary or binary operators) offers the simplest and most effective approach. This also simplifies the code by eliminating the need to manage and store previous values. In the future though, we could consider adding a warning to help mitigate the risk of data loss.

ivanvpetrov commented 2 weeks ago

@sdimchevski 1 In my opinion, from user stand point it's irritating to loose your input data. 2 I don't see any real reason to clear the search value, since it's 'left over' existence won't cause any unexpected behavior. 3 In Excel, which I believe is our reference point, changing the operator doesn't clear the input.

I have a working solution to this issue, which I'll be happy to share. My question beforehand is, from you perspective which is the best presentation of a disabled field? (Or maybe suggest something else):

image

Thank you

P.S. There is a presentational PR for the approach I'm suggesting https://github.com/IgniteUI/igniteui-angular/pull/15011

sdimchevski commented 1 week ago

@ivanvpetrov I'm concerned about complexity or causing confusion, that's why I suggested a simpler, more predictable approach but you may be right - users who frequently switch between unary and binary operators might find it annoying to re-enter their value, especially if they’re experimenting with different operators to build or refine queries. The closest to an effective disabled state is number 2 though we may consider using “Disabled” or “Not Available,” which explicitly conveys that the field is disabled. This will make it unmistakably clear to the user that the input is currently not in use and cannot be interacted with. N/A is fine too.