{"action":"created","issue":{"url":"https://api.github.com/repos/18F/openFEC/issues/797","labels_url":"https://api.github.com/repos/18F/openFEC/issues/797/labels{/name}","comments_url":"https://api.github.com/repos/18F/openFEC/issues/797/comments","events_url":"https://api.github.com/repos/18F/openFEC/issues/797/events","html_url":"https://github.com/18F/openFEC/issues/797","id":78354372,"number":797,"title":"Load candidate and committee search results asynchronously","user":{"login":"jmcarp","id":1633460,"avatar_url":"https://avatars.githubusercontent.com/u/1633460?v=3","gravatar_id":"","url":"https://api.github.com/users/jmcarp","html_url":"https://github.com/jmcarp","followers_url":"https://api.github.com/users/jmcarp/followers","following_url":"https://api.github.com/users/jmcarp/following{/other_user}","gists_url":"https://api.github.com/users/jmcarp/gists{/gist_id}","starred_url":"https://api.github.com/users/jmcarp/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jmcarp/subscriptions","organizations_url":"https://api.github.com/users/jmcarp/orgs","repos_url":"https://api.github.com/users/jmcarp/repos","events_url":"https://api.github.com/users/jmcarp/events{/privacy}","received_events_url":"https://api.github.com/users/jmcarp/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":3,"created_at":"2015-05-20T03:44:55Z","updated_at":"2015-05-20T21:49:58Z","closed_at":null,"body":"Loading candidate or committee search results is currently a synchronous operation, meaning that the entire page is re-rendered server-side on selecting a different results page or updating search filters. This makes the search slower than it has to be and puts unnecessary load on the webapp server. Proposal: fetch search results asynchronously, ideally by making a request directly to the API and bypassing the webapp entirely.\r\n\r\nSeparate but related: revisiting the way we fetch search data would also give us an opportunity to use a table library with more features (sorting, more complete paging interface) before we start building those features ourselves. I've had good results with datatables in the past, but would be open to any library (or none).\r\n\r\nhttps://www.datatables.net/"},"comment":{"url":"https://api.github.com/repos/18F/openFEC/issues/comments/104049089","html_url":"https://github.com/18F/openFEC/issues/797#issuecomment-104049089","issue_url":"https://api.github.com/repos/18F/openFEC/issues/797","id":104049089,"user":{"login":"jmcarp","id":1633460,"avatar_url":"https://avatars.githubusercontent.com/u/1633460?v=3","gravatar_id":"","url":"https://api.github.com/users/jmcarp","html_url":"https://github.com/jmcarp","followers_url":"https://api.github.com/users/jmcarp/followers","following_url":"https://api.github.com/users/jmcarp/following{/other_user}","gists_url":"https://api.github.com/users/jmcarp/gists{/gist_id}","starred_url":"https://api.github.com/users/jmcarp/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jmcarp/subscriptions","organizations_url":"https://api.github.com/users/jmcarp/orgs","repos_url":"https://api.github.com/users/jmcarp/repos","events_url":"https://api.github.com/users/jmcarp/events{/privacy}","received_events_url":"https://api.github.com/users/jmcarp/received_events","type":"User","site_admin":false},"created_at":"2015-05-20T21:49:58Z","updated_at":"2015-05-20T21:49:58Z","body":"I don't *love* datatables--it's been in development for a long time, and there's a certain amount of cruft in the codebase. But it's also very mature and supports all the features we need out of the box (including server-side sorting and pagination, which isn't hard, but I'm generally in favor of writing less code if possible). Then again, using datatables might also require adding a custom API endpoint (not hard, but kind of annoying!), so maybe it's not worth it. I'll think about this more--any feedback / alternatives welcome."}}