Semantic-ui: [Dropdown] hideAdditions should be false by default

[elamm2040]

i have a Dropdown with property allowAdditions but is not working, how do I fix this?

my code:

<div class="ui multiple search selection dropdown">
    <input type="hidden"> <i class="dropdown icon"></i>
    <div class="default text">Animals</div>
    <div class="menu"></div>
</div>

$('.ui.dropdown').dropdown({
    allowAdditions: true
});

[groeney]

I'm having this same issue since upgrading from SUI 2.1 to 2.2.1. Sorry I don't have any solutions as yet.

To clarify my problem:
message: { addResult: 'Add {term}' } is not displaying. When there is no match in the menu, the dropdown menu simply closes with no UX indicating that the user can add a new term. The example in the docs also seems to be behaving this way -- http://semantic-ui.com/modules/dropdown.html#/examples

Important: A new label does indeed get created and added after user hits enter.

So I guess technically allowAdditions is working, though the UX is a little off.

@jlukic is there a known issue with 2.2.1 selection dropdown allowAdditions UX?

[JakeAlmer]

Broken for me also. Reproduced in the dropdown demos (http://semantic-ui.com/modules/dropdown.html#tagging-and-user-additions). Chrome 51.0.2704.106 m.

[JakeAlmer]

Looks like the change was introduced in 65624294f87c0672d20bf5b0be3c08a680c48194. I'm having trouble telling if it was on purpose or not. Previously you did not need to specify hideAdditions, now you do.

jsFiddle showing the difference

[swendrich]

Same here! Would be great if the old behavior is brought back. Using hideAdditions: false fixed it.

[OleksandrK]

Thank you Swendrich, you saved me a lot of time!
The value of hideAdditions should be just false by default (imho).

[richardtallent]

In case anyone else googles and finds this, the "search" class is required for allowAdditions to work. This is not clear in the documentation.

[whymahyah]

Is there way to disable case sensitivity on allowAdditions?

[awgv]

@whymahyah not that I know of. There’s a PR #3432 that might make it into the next release, but it will take a while.

Closing the issue as resolved.

[JakeAlmer]

@Banandrew why is this resolved? @whymahyah question was unrelated to the original issue reported.

As originally asked, was the change in behavoir a desired change or a mistake?

[awgv]

@JakeAlmer I understand that the question was unrelated; it was resolved, because I thought it was a usage question. I don’t know if the change was a mistake, and Jack has his hands full currently—frankly, I don’t think it matters at this point. Would you prefer hideAdditions to be false by default?

[ClydeDroid]

Makes more sense to have hideAdditions be false by default, because that's how it was before it became a new option. Having it true by default breaks previous behavior. Though I can see how it is a useful option to have!

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 30 days if no further activity occurs. Thank you for your contributions.