Performance of the case when there's a lot of native options

[krasnoukhov]

I have a case with a native select box that renders like a hundred of options, and with select-box/native it takes like 300-400ms to do that.

So I was wondering if that can be improved and my idea was to render the options in bulk within a single component. I know that this is much less "ember way", but that seems to be 5-6x faster then original approach.

Do you think having that would be valuable for the project? Here is the commit with a draft version: https://github.com/simplepractice/ember-select-box/commit/c94aa0e0711d7a3d3dc969201f32d9ccb7df36ac

Thanks!

[amk221]

We have similar issues with rendering lots of components in our Ember app. As you probably know, with Glimmer re-rendering is fast, but initial render is slow. I've been holding out hope that Glimmer 2 will improve things.

ember-select-box can't know what options are available until they have rendered - so it has to wait until it has rendered. Then, after that - it builds an array of the options components. Therefore - if you have lots, this will be slow.

Having access to the option components is more useful than a 'fake' hash, as you won't be able to send actions to a specific option component e.g. sb.select(value) (so, your changeset might break a few things, however - I guess they might not be applicable to the native version so it might not matter).

I think perhaps for yourself, in this case, there are no benefits to using ember-select-box for in order to get a native select element, which can now be created quite easily (albeit with the use of truth helpers, or 'decorator' CPs).

Using <option> elements is obviously way faster (no components to construct) however, one down side is you can't set the value to be an Ember object e.g. <option value={{myModel}}>, the value just becomes stringified to [object Object].

Another blocker is the fact that because they are not components, they don't get registered with the select-box, and so when the user makes a selection, the select-box component thinks it has no options. (I tried that here).

The main goal of ember-select-box is to make it easier to create lots of different types of faux-select boxes. The native select box was really a side effect, which is included because everybody usually needs it at some point or another.

So, to answer your question - I don't think your draft technique should be included in the repo by default. But you could extend the select box overriding the change event and using different selection technique. (Perhaps by using $('option:selected').val() instead of option.get('value')).

Please let me know what you think? I definitely do share your concerns!

[krasnoukhov]

Thanks for such detailed comment! I totally agree with that. Extending component with custom change event would work, so I'll go ahead and close this. I hope that this would be helpful if someone hits the same problem

[amk221]

@krasnoukhov I've added this, I wonder if you could try it? (code, tests)

Although, just a reminder that these days you can just do: twiddle.

[krasnoukhov]

@amk221 Thanks for the update, I actually hacked together solution similar to the one you just added, so I think that should work for me. I'm going to try it next week