sdemjanenko
commented
9 years ago We could do this. I am hesitant since running an autocomplete query ties up a rails worker for ~100ms. We only have 8 rails workers right now (we can serve 8 requests simultaneously). If the user is typing a lot I could see them filling up this queue. This could already happen when adding an author (but its less common).
I've been giving a lot of thought about this. One possibility is to switch to node.js where a single worker can handle multiple requests simultaneously. This is probably our best bet since I'm very familiar with Node and it has a large developer community.
Ive also been giving some thought to switching to Erlang via Elixir + Phoenix. A drawback to this would be fewer developers know these technologies (and I would be learning it myself).
This would presumably be a very similar implementation as what we currently have when adding authors, which works very well!
Note, this would also be implemented for the search box on the "Add replication" modal window.
Here's what it should look like:
That is, possible matches will be listed formatted in the following way: Author last names (2 max), publication year, and article title. For example, "LeBel & Smith (2014) - Heightened anxiety to stress response", "LeBel et al. (2014) - PsychDisclosure.org: Grassroots support for new reporting standards"
For the main search box, once user clicks on the relevant article in the list, it will bring them directly to the article page for that article.
For the search box on the add replication window, once user clicks on relevant article in the list, it will simply list that article within the add replication window and EXPAND it by default so that the user can immediately click on the relevant replication study(s) they want to link to the original study. Here's what this should look like exactly: