Change searchPlaceholder depending on the filterable property

[MonikaKirkova]

Closes #14340

Additional information (check all that apply):

• [ ] Bug fix
• [x] New functionality
• [ ] Documentation
• [ ] Demos
• [ ] CI/CD

Checklist:

• [x] All relevant tags have been applied to this PR
• [x] This PR includes unit tests covering all the new code (test guidelines)
• [ ] This PR includes API docs for newly added methods/properties (api docs guidelines)
• [ ] This PR includes feature/README.MD updates for the feature docs
• [ ] This PR includes general feature table updates in the root README.MD
• [x] This PR includes CHANGELOG.MD updates for newly added functionality
• [x] This PR contains breaking changes
• [x] This PR includes ng update migrations for the breaking changes (migrations guidelines)
• [ ] This PR includes behavioral changes and the feature specification has been updated with them

[Lipata]

@sdimchevski With this PR in igniteui-angular we are always making filtering available and removing the option to enable/disable it. This is a little bit different from what is in igniteui-webcomponents, where we have the disableFiltering option available.

You can see that in angular sample, disabling the filter will not remove the search input, just will stop the filtering and reduce the list. While in the webcomponent sample when filtering is disabled, then the search input is removed.

On one hand, we want to have consistency between different platforms. On the other hand disabling the filtering may not be a common scenario, but would appreciate any design input from you on the matter.

[sdimchevski]

@sdimchevski With this PR in igniteui-angular we are always making filtering available and removing the option to enable/disable it. This is a little bit different from what is in igniteui-webcomponents, where we have the disableFiltering option available.

You can see that in angular sample, disabling the filter will not remove the search input, just will stop the filtering and reduce the list. While in the webcomponent sample when filtering is disabled, then the search input is removed.

On one hand, we want to have consistency between different platforms. On the other hand disabling the filtering may not be a common scenario, but would appreciate any design input from you on the matter.

@Lipata @kdinev From a UX point of view, right now in Angular it’s not OK and is confusing to set filtering disabled and still have the search option. The behavior in Angular is actually the same as in Web components, once you switch off the Allow Custom Values feature (there is no such feature in WebC at the moment). So instead of removing the option to enable/disable the filtering in Angular, when we have the filtering disabled and the Allow Custom Values enabled, why don't we change the Placeholder from Search to Add Item?

[kdinev]

@sdimchevski With this PR in igniteui-angular we are always making filtering available and removing the option to enable/disable it. This is a little bit different from what is in igniteui-webcomponents, where we have the disableFiltering option available. You can see that in angular sample, disabling the filter will not remove the search input, just will stop the filtering and reduce the list. While in the webcomponent sample when filtering is disabled, then the search input is removed. On one hand, we want to have consistency between different platforms. On the other hand disabling the filtering may not be a common scenario, but would appreciate any design input from you on the matter.

@Lipata @kdinev From a UX point of view, right now in Angular it’s not OK and is confusing to set filtering disabled and still have the search option. The behavior in Angular is actually the same as in Web components, once you switch off the Allow Custom Values feature (there is no such feature in WebC at the moment). So instead of removing the option to enable/disable the filtering in Angular, when we have the filtering disabled and the Allow Custom Values enabled, why don't we change the Placeholder from Search to Add Item?

I agree with your suggestion and if the placeholder displays the correct prompt, then I'm OK.

[MonikaKirkova]

@sdimchevski, @kdinev Except changing the placeholder, should we remove the filterable from the filteringOptions and rename the filterable property to disableFiltering as in the web components.

[kdinev]

@sdimchevski, @kdinev Except changing the placeholder, should we remove the filterable from the filteringOptions and rename the filterable property to disableFiltering as in the web components.

Yes, please do that!

[damyanpetev]

@MonikaKirkova Since we want to have the search placeholder change between filtering & custom value state being enabled, it might not be bad idea to have those placeholders in the resourceStrings for the Combo. That's now hardcoded in English in the @Input() searchPlaceholder, but since it'll be dynamic I think we should deprecate the input and leave it empty by default.

PS: Talking of localization, there are also string of hardcoded English in the markup like "Clear Selection" and Add item which should all be localizable and in the resource strings. Could be a separate task ofc for any such strings you find.