Skip to content

Combining Search View and Docsearch #6341

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

Closed
dojutsu-user opened this issue Oct 31, 2019 · 5 comments · Fixed by #7255
Closed

Combining Search View and Docsearch #6341

dojutsu-user opened this issue Oct 31, 2019 · 5 comments · Fixed by #7255
Labels
Needed: design decision A core team decision is required

Comments

@dojutsu-user
Copy link
Member

Currently we are serving the search results from two locations:

  • Docsearch API (via DRF)
  • Main Site Search (via Django Templates)

This creates many problems:

  • Maintaing the same code in two place
  • Adding a feature requires more work
  • More code redundancy and code complexity.

It will be better if we have one API endpoint for both the use cases.

Proposed Solution:
For this, we can make use of TemplateHTMLRenderer along with JSONRenderer.
Django Rest Framework allows multiple renderer_classes to be defined in a view. We can have renderer classes for json and html. We can continue serving the docsearch with the json response and for main site search we can have search-as-you-type. As soon as the user starts typing, we will get new API response in html form and we can render that as it is.

@humitos
Copy link
Member

humitos commented Nov 1, 2019

I don't have the full context for this, but from the description, it seems a good path forward to me. I have some questions:

  1. does this refactor involve too much work?
  2. is required for this refactor "search-as-you-type in the main site" or that can be done in a separate work?

I'd say to go ahead with this if the combination is simple and does not change the current behavior. I don't think this is in our current roadmap and my concern is not having too much time for review if the PR grows too much.

@ericholscher
Copy link
Member

I think the main concern is around shipping rendered HTML over the API. We're starting to move away from HTML API responses to JSON responses that are built on the client side. What are the benefits of the HTML approach, when we're using the JSON approach already in the doc pages?

@stsewd stsewd added the Needed: design decision A core team decision is required label Nov 13, 2019
@humitos humitos added this to the Search improvements milestone Nov 18, 2019
@Blackcipher101
Copy link
Contributor

Blackcipher101 commented Jan 14, 2020

@stsewd can I start working on the issue

@stsewd
Copy link
Member

stsewd commented Jan 14, 2020

@Blackcipher101 this issue has the Needed: design decision label, we still need to decide how to resolve this.

@Blackcipher101
Copy link
Contributor

@stsewd fine

stsewd added a commit that referenced this issue May 13, 2020
Looks like user and filter_by_user are still
needed in .com for filtering results in the dashboard (#6341).
But it can be removed from tests.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Needed: design decision A core team decision is required
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants