Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Render suggestions in iron-list #104

Open
nomego opened this issue Dec 15, 2017 · 5 comments
Open

Render suggestions in iron-list #104

nomego opened this issue Dec 15, 2017 · 5 comments

Comments

@nomego
Copy link
Contributor

nomego commented Dec 15, 2017

When providing a lot of suggestions, the dropdown is very slow, I have to limit it to around 30 to avoid it being sluggish.
To work around this, I think moving to iron-list would enable unlimited suggestions.

@jhuesos
Copy link
Collaborator

jhuesos commented Dec 15, 2017

How many elements are we talking about? I would argue that the whole point of autocomplete is to prevent displaying too many elements.

About your suggestion, my only concern of using iron-list is that it will increase the number of dependencies on this component and therefore increase bundle size. I would have to check how much bigger it will grow

@ndormont
Copy link

I agree with Jaime, the suggestion list should be kept under 10 (IMHO). I personally leave the default value to 5 suggestions max. It's not very user friendly to offer more than 10 suggestions to a user, in a suggestion list. More results should be displayed in a separate container/page.

@nomego
Copy link
Contributor Author

nomego commented Dec 18, 2017

Our UX disagrees, if the user suggestion selection is limited, the user needs to be informed that additional options are available (with a refined search).
If users are presented with too many suggestions, they will likely refine the search further.
Also we work with lists where options are very similar, so users might do a partial search, start sifting through suggestions, and optionally search further.

Since iron list would enable a complete result set without hampering performance, it would be a far better approach than "showing 5/3219"

@jhuesos
Copy link
Collaborator

jhuesos commented Dec 18, 2017 via email

@nomego
Copy link
Contributor Author

nomego commented Dec 18, 2017

We're still on 1.x but our 2.x branch is expected to be merged before 2018 :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants