foundation / foundation-sites

The most advanced responsive front-end framework in the world. Quickly create prototypes and production code for sites that work on any kind of device.
https://get.foundation
MIT License
29.67k stars 5.48k forks source link

Custom dropdowns really slow with a large amount of items #2119

Closed sergio-bobillier closed 11 years ago

sergio-bobillier commented 11 years ago

I'm implementing a country list with Foundation's custom dropdowns, like this:

<form class="custom">
    <label for="customDropdown1">Medium Example</label>
    <select id="customDropdown1" class="medium">
        <option DISABLED> -- Select -- </option>
        <option value="CO">Colombia</option>
        <option value="AR">Argentina</option>
        <option value="CL">Chile</option>
        <option value="EC">Ecuador</option>

        ...

    </select>
</form>

The list has about 250 entries.

The thing is that selecting an element on the list is extremely slow it takes about 2-3 seconds for the item to get selected and the list to be closed.

I don't know the details of the internal implementation of the custom dropdown but the performance is really poor.

Maybe another method is needed to select the correct element in the underlying dropdown. A proposed fix wold be to add the value of the item to the li tags on the custom dropdown to improve the performance.

emilhem commented 11 years ago

I've had the same problem and I just don't use it for long lists of items, my select contains 2000 items though and even with the native select it lags loading the page. It also depends on the web browser. Which one are you experiencing difficulties with?

sergio-bobillier commented 11 years ago

We tested it in Chrome, Safari and Firefox and the same issue arises in all of them. It varies according to the computer the browser is running on but the performance is generally bad.

emilhem commented 11 years ago

Indeed it is bad. I like your idea of the fix. I also think that a fix in the jQuery selectors could speed it up. I didn't check the source code but perhaps there are some way of optimizing it. Example:

$("form .the_general_class #the_specific_id")

is commonly faster than:

$("#the_specific_id")
noslouch commented 11 years ago

Don't jquery selectors typically read R to L?

So if your most specific selector is last (furthest right), wouldn't it be faster to find one unique selector vs one unique selector that is a descendent of a class that is the descendent of an element?

On Friday, April 5, 2013, Emil Hemdal wrote:

Indeed it is bad. I like your idea of the fix. I also think that a fix in the jQuery selectors could speed it up. I didn't check the source code but perhaps there are some way of optimizing it. Example:

$("form .the_general_class #the_specific_id")

is commonly faster than:

$("#the_specific_id")

romanbsd commented 11 years ago

Profiling javascript shows, that almost all of the time is spent in refreshCustomSelect. In our case, as no refresh was needed, the workaround was to do $('#country').attr('data-customforms', 'disabled'); AFTER the custom dropdown was created. If I get it right, then the 'change' event is actually triggered by Foundation, so no refresh is needed.

hatefulcrawdad commented 11 years ago

We're pushing fixes to this to master soon. This is a duplicate from another issue so I'm closing it down. Thanks for being patient.

dragthor commented 9 years ago

What was the duplicate issue number?

dragthor commented 9 years ago

Mobile view... http://www.barenecessities.com/Bras_catalog_nxs,31.htm ... the Size filter dropdown is really slow.