Enhance Search bar with autosuggestion and pagination from client based to server based

[Hayat4144]

Is this a unique feature?

• I have checked "open" AND "closed" issues and this is not a duplicate

Is your feature request related to a problem/unavailable functionality? Please describe.

The current implementation of the search bar employs a client-side pagination strategy, leading to suboptimal performance, especially when dealing with large datasets. One major concern is that the entire document is loaded into the client's memory, resulting in increased latency and potential performance bottlenecks.

The current approach may cause delays in rendering search results, leading to a suboptimal user experience. Users may experience laggy interactions and slower page loads, affecting the usability of the search functionality.

Proposed Solution

I propose enhancing the current search functionality by adding an autosuggestion feature to the existing search bar and optimizing pagination from client-based to backend-based for improved performance.

Feature 1: Autosuggestion in Search Bar

Implementing autosuggestion in the search bar can significantly improve the user experience by providing real-time suggestions as users type. This feature can help users refine their search queries, discover relevant content faster, and reduce the likelihood of typos or errors in their input.

Feature 2: Backend Pagination for Improved Performance

Currently, pagination is handled on the client side, which may lead to suboptimal performance, especially when dealing with a large dataset. By transitioning to backend pagination, we can improve the efficiency of data retrieval and reduce the load on the client. This change can result in faster page load times and a smoother overall user experience.

Proposed Changes:

Autosuggestion in Search Bar

1. Implement a mechanism for real-time autosuggestions as users type in the search bar.
2. Provide an option for users to easily select and apply suggested queries.

Backend Pagination:

1. Refactor the pagination logic to be handled on the server side.
2. Introduce API endpoints that support paginated data retrieval, allowing clients to request specific subsets of data.
3. Update the client-side implementation to make use of the new backend pagination endpoints.

Screenshots

Here is the some of the screen shot how the ui will looks after the changes.

Do you want to work on this issue?

Yes

If "yes" to above, please explain how you would technically implement this

I already solve this problem with mongodb search index and aggregation . if you agree with this features i will make a pull request.

[github-actions]

To reduce notifications, issues are locked until they are 🏁 status: ready for dev You can asked for this issue to be assigned (if not already assigned) and to be assigned. You can learn more in our contributing guide https://github.com/EddieHubCommunity/BioDrop/blob/main/CONTRIBUTING.md

[sital002]

@Hayat4144 Thanks that's a great description on the issue. Can you explain how the auto suggestions work will it make network request to the server on every onChange
event.

@eddiejaoude What are your thought on this.

[Hayat4144]

Let me explain the how we achieve it .

When we building features like auto suggestion, one thing makes into mind is performance and I am agree with it. The search page is combination of different components, we will create a separate components for search which will prevents re-render of the parent component.We will not making server request on every onChange event ,instead we will use debouce concept . It means when the user stop typing then we will make a server request and instead of using useState hook for managing input tag value we use search params and set it default value of input tag.

And on the Backend side , we will create two index in mongodb atlas first one is for search and second one is for autosuggestion . we will create a new api route for autosuggestion called /api/search/autosuggestion , this endpoint handle the autosuggestion functionality with mongodb aggregation pipeline with limit to 7-10 suggestion at a time . In existing api routes called /api/search we will make some changes we will receive the tags or username in search query and create unique aggregation pipeline for both scenario . The existing code will read the whole model documents and use client side pagination which is inefficient and time consuming process. we ensure to use aggregation pipeline with pagination and limit the data to read.

[eddiejaoude]

This sounds great 👍 awesome collaboration 💪

I have a question, will this also working on a local version of mongo? So dev (local) will be the same as prod (Atlas)? I heard this is now possible with recent changes by mongo

[Hayat4144]

According to my current knowledge ,the autosuggestion and full text search is only available in Cloud Atlas . I don't know autosuggestion and full text search feature exist or not in recent version of mongodb . I will check it and informed you if I get any information related to it.

[Hayat4144]

I don't think so the autosuggestion is available in mongodb in Os. It is only exist in cloud.

[eddiejaoude]

I don't think so the autosuggestion is available in mongodb in Os. It is only exist in cloud.

How would this affect developing locally? Would it break or return no results or something else?

[Hayat4144]

It throw error in local development , but we can prevent it from error. Here is the solution for it.
We use Atlas cloud for production and local mongodb while in development mode. We write logic for handling search functionality based on the app environment in both in frontend and backend , if it is in development mode we use previous logic and if it is production mode we use atlas search logic same with frontend. we just changed ui nothing more than it.

Here is basic code how it will be done :

```js
const SeachLogic= ()=>{
   if(!development){
  // here is  production logic
  }else{
  // development login
   }
}

[akshat-khosya]

We can use concept of tries to autocomplete the words that user trying to enter, just like google search.

[eddiejaoude]

We write logic for handling search functionality based on the app environment in both in frontend and backend

I am not keen on this because it will create not only extra code but also when we get bugs and we won't know about them