ux icon indicating copy to clipboard operation
ux copied to clipboard

[Autocomplete] Don't want a clear button

Open maartendekeizer opened this issue 2 years ago • 4 comments

A clear button is automaticly added when the autocomplete is not disabled and not multiple:

        if (!this.formElement.disabled && !isMultiple) {
            plugins.clear_button = { title: '' };
        }

How can we always disable the clear_button plugin?

Already tried, but that will result in a error

{{ stimulus_controller('symfony/ux-autocomplete/autocomplete', {tom_select_options: {maxItems: 1, plugins: {clear_button: null}}})}}

maartendekeizer avatar Jul 05 '22 06:07 maartendekeizer

Yea, we should make this configurable somehow. We could do it as you suggested (maybe changing it to clear_button: false instead of null) or we could add a new option as a "sibling" to tom_select_options:

{{ stimulus_controller('symfony/ux-autocomplete/autocomplete', {
    plugins: { remove_button: { title: '' } }
})  }}

The idea is that IF you supply plugins, then YOU become 100% in control of the plugins enabled: we would no longer attempt to add any default plugins for you - i.e. none of this code would run - https://github.com/symfony/ux/blob/6afcd61e340f3298b26246202c9901e93780abd5/src/Autocomplete/assets/src/controller.ts#L51-L61

I think that's the best option - PR welcome :)

weaverryan avatar Jul 06 '22 21:07 weaverryan

@weaverryan That will break implementations where extra (non default activated plugins) are added. That is not a problem?

maartendekeizer avatar Jul 07 '22 06:07 maartendekeizer

Hmm, I'm not sure I understand the problem you're thinking of. My thinking is that if you pass this plugins option, then we would start the configuration with plugins = {}. If you are currently adding additional plugins via { tom_select_options: { plugins: { ... }} }, that would still work fine: your plugins would override the empty {}. Or is there some situation that I'm not seeing?

weaverryan avatar Jul 11 '22 13:07 weaverryan

@weaverryan I agree with your solution and made a PR for that. The issue I mentioned was about backwards compatibility. Implementations that have defined the plugins property with the drag_drop plugin will currently have the drag drop plugin and the default plugins. After this change they only have the drag and drop plugin because the default plugins are not explicitly defined.

maartendekeizer avatar Jul 26 '22 10:07 maartendekeizer