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

Auto-Complete for Search Box #727

Open
gbaz opened this issue Mar 24, 2018 · 4 comments
Open

Auto-Complete for Search Box #727

gbaz opened this issue Mar 24, 2018 · 4 comments

Comments

@gbaz
Copy link
Contributor

gbaz commented Mar 24, 2018

Good suggestion. The question is what we auto-complete to? I suppose package names, possibly tags...

(we could also have jump-to-package on exact match. but we'd want to not force that on users, but only make it optional -- need good ui for that)

@hvr
Copy link
Member

hvr commented Mar 24, 2018

fwiw, we have autocomplete at http://matrix.hackage.haskell.org/ ; that requires to seed the webbrowser with a JSON array of all package names

@saevarb
Copy link

saevarb commented Mar 24, 2018

I think the auto-complete at http://matrix.hackage.haskell.org/ is very nice.

Is it desirable to avoid seeding the browser with all the package names? Looking at the API call that's being made, https://matrix.hackage.haskell.org/api/v1.0.0/package/list/?count=100000, it seems to be limiting it to a 100.000 packages. The returned response is roughly 600 kilobytes of JSON. In the grand scheme of things, it's not a lot(and probably made a lot less by compression), but I think it can still be avoided.

We could simply send an API call upon typing a character, which would then limit the response to packages starting with those characters. In order to avoid hitting the API too much, we could just cache the responses so that if I type a, then delete it, and type a again, we don't need to hit the API again.

@gbaz
Copy link
Contributor Author

gbaz commented Mar 24, 2018

I think that would put more load on the server and also decease overall responsiveness. We can cache and share the file, if it is fixed, and only generate it rarely on the server. (and also only fetch it periodically for the client -- imho it is ok if auto-completion lags the db for up to 24 hours or more).

@hvr
Copy link
Member

hvr commented Mar 24, 2018

fwiw, that's actually the old faked API; the new API (which isn't live yet) just sends a [Text] array; and it's very cheap server-side to send it (and it's also very CDN friendly, as it uses Etags based on hasing the data); however, the important bit is to send that list lazily; as it does take a bit of processing time in the browser to decode and process that large array. IOW, there's no need to introduce a 24h delay; it's perfectly doable to keep it fresh!

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