Optional search option

[sadeghbarati]

How to disable search for simple select ?

[ToshY]

I think you are looking for the same thing as I did, which is wanting select options without the input element. You can achieve this by explicitly setting the controlInput to null.

Example:

new TomSelect('#my-select', {
    create: false,
    highlight: true,
    closeAfterSelect: true,
    controlInput: null
});

Even though the docs state that null is the default, that doesn't seem correct. Probably needs an update there.

[FritzHerbers]

That setting this option does the trick, should be better documented.
Maybe providing an explicit option, e.g. disableSearch, would be far better understandable.
Also having an example.

[MatthewKennedy]

I'd love some option to only display the search input when the option count is above a certain number.

new TomSelect('#my-select', {
    create: false,
    highlight: true,
    closeAfterSelect: true,
    showSearchInputWhenOptionCountIsGraterThan: 15
});

[sadeghbarati]

@ToshY

worked but placeholder now gone ( placeholder attr on select element )

---

maybe with js placeholder option

new TomSelect('#my-select', {
    create: false,
    highlight: true,
    closeAfterSelect: true,
    controlInput: null,
    placeholder: "test placeholder"
});

[ToshY]

@sadeghbarati Yes, sadly the placeholder gets removed because by setting the controlInput to null you don't get an input element anymore, which is where normally the placeholder gets added.

Ideally it would be better to have a separate element for the placeholder, e.g. <span class="ts-placeholder"></span>, so that it can be used with or without the input element (and it would also allow custom HTML). I've created a topic regarding that idea.

[TixieSalander]

I spent a bit of time on my own searching on how to disable the search after reading on the available settings on the documentation before ending there, I'm maybe not the only one.

I'm wondering why controlInput default value is declared as null in the documentation but actually isn't. And why this setting made to "supply a custom element" is used to actually disable the input when the null value is actually set in the config?

It's my first time using the plugin so I'm not familiar with the historic background, but looks like the controlInput default value was commented because of focus problem on mobile. I haven't check by myself but since the issue is closed I can guess it's fixed. However the default value is still currently commented. Is there another reason to keep it that way?

In the case of the default value is gonna be set as null again, is the input gonna be disabled by default and the only way to have it would be to set a custom input?

To summarize I see three different states:

• input generated but the plugin (probably the default option we want for no breaking change)
• custom input (targeted through the config)
• disabled input

What would be the best solution to allow those three states to be more clear?
I have two ideas:

1. Set the default value of ControlInput (input generated by the plugin) to undefined, and continue to use null to disable it (and maybe clarify the two options in the doc)
2. Create a dedicated setting to disable the input

What's do you think?

The commenting commit mention a plugin and I'm not familiar at all with the effects my propositions could have on the plugin ecosystem, so feedback on that are more than welcome.

[oyejorge]

I'm wondering why controlInput default value is declared as null in the documentation but actually isn't.

Oops, docs are not correct. By default, the controlInput setting is undefined.

It's my first time using the plugin so I'm not familiar with the historic background, but looks like the controlInput default value was commented because of focus problem on mobile

The default value was commented out so that passing a null value could be repurposed to disable the input.

I think what we have in place is already consistent with your ideas... we just need to update the docs.

[TixieSalander]

Thank you a lot for your quick answer!

Oops, docs are not correct. By default, the controlInput setting is undefined.

For what i see it's not that the controlInput default value is undefined but that it's the property existence who is checked.
The result is an inconsistent behavior in the case I setup controlInput: undefined (or false by the way) in my config, it will have the same behavior than setting it to null: disable the input

Do you think it's something that should be improved to have a more consistent API?
I can create an issue (and maybe look into it if I have time) if needed.

[TixieSalander]

Had another idea on how manage the three different states in a more elegant and clear state (not a fan of using undefined AND null): combine a boolean type and the node type (for the custom input):

• true (default): there is a controlInput
• false: controlInput disabled
• node: custom controlInput

It's means a breaking changes. In a way the last version is still in not stable (rc5 i think?) so maybe it's the last time to integrate breaking changes, on the other hand the RC version is the default version published on npm so heh 😬

[oyejorge]

For what i see it's not that the controlInput default value is undefined but that it's the property existence who is checked

Right, I didn't explain that correctly. The the states are: not set, null, and node.

Without introducing breaking changes, the three options could be:

• string: default would be <input type="text" autocomplete="off" size="1" />
• null: controlInput disabled (or undefined, false)
• node: custom controlInput

[TixieSalander]

Okay, seems good to me as long as the documentation become more explicit about it.
There maybe could be better way to manage types in this API, but I agree to give priority in preventing breaking changes.

Just to be sure, when you mention a string type: does that mean you can give serialized HTML and the plugin can manage it? If it's the case, indeed it seems another reason to complete the doc, I didn't know it was possible.

[sadeghbarati]

things in tom-select not covered in documentation:

1. mentioned how to use with bootstrap 4 and 5 but do not mention how to use in Bootstrap Modal ( select element outside of modal ) like Select2

2. change default options for example, change render option once instead of writing same code in every tom-select instances

new TomSelect('#tom-select-one', {
	render:{
		no_results: function( data, escape ){
			return '<div class="no-results">change no result render</div>';
		},
	}
});

new TomSelect('#tom-select-two', {
	render:{
		no_results: function( data, escape ){
			return '<div class="no-results">change no result render repeated</div>';
		},
	}
});

3. tom-select also trigger native select element or not ? if it's trigger 4

4. if tom-select trigger native select, how to use native select element on mobile ( popup window ) i konw it's duplicated no need to mention that, but if you give a tip, it will be very good
   4.1 getValue work for both native and customized selectbox by tom-select

5. contributing ?

[TixieSalander]

I'm not sure to understand the link between those points and the controlInput option.

[coudrak]

Another possibility, just add readonly:

	new TomSelect('#my-select', {
		onFocus: function() {
			this.control_input.setAttribute("readonly", true);
			this.control.style.cursor = 'pointer';
		}
	});

[MatthewKennedy]

It would be nice if there was a plugin that counts the number of options and if the option count is above a set number, then a search field is enabled.

So a tom select with only 10 options would appear as a simple dropdown, but anything with over 11 or more options would have a search box.