Project-Nexus
Project-Nexus copied to clipboard
Add search and search bar
With more posts created more frequently than before, it would be more convenient if we had a search bar through which we could search for specific posts based on their:
- Title
- Author
- Category
I'm willing to look into this. Do you mean to have a search bar for regular(typed) search queries, and another system for filtering by title, author, and category?
No, I meant that we can have a normal search bar that only produces relevant search results. Filtering posts can be done once the search results are displayed.
Let's ensure that some search results are displayed right below the search bar. And once the user clicks the search button, or hits the return key, we display all relevant results, keeping in mind that we should limit the number of posts displayed at a time with a Load more button to bring in more posts as and when required.
Let's ensure that some search results are displayed right below the search bar.
I'm unsure of exactly what you mean, can you please elaborate?
Instead of a Load more button, can we paginate the results?
I mean, you can do that. I just suggested it since we already have such a feature implemented for the homepage. If pagination seems the right way to do it, you can use it.
This has been taken care of by @Sam-Takahashi in PR #110
The search bar code has created an app-breaking issue where it won't let the app initialize at all.
Here is how the live deployment at https://projectnexus.netlify.app looks

Here's what the console says

Here console shows an error in App.js:43 which looks like this

I think the search needs a bit more refinement.
Would you like to take it up? @vikashjajra
Sure... I have made a change that fixes the error for the moment in #113 , but the search works only on post titles now. I will try to fix it so the search can be performed on the author and the post content as well.
Hi, creator of the search bar here.
It appears item[key] is undefined. Have there been any changes to the API/endpoint?
Let me know if the problem persists @vikashjajra and I'll look into it.
Hi, creator of the search bar here. It appears
item[key]is undefined. Have there been any changes to the API/endpoint? Let me know if the problem persists @vikashjajra and I'll look into it.
There seem to be no changes in the APIs.
Hi, creator of the search bar here. It appears
item[key]is undefined. Have there been any changes to the API/endpoint? Let me know if the problem persists @vikashjajra and I'll look into it.
I've been fiddling around with the code and found that when we remove the username from the keys array in App.js, it works fine. but adding it back recreates the problem.
I've been fiddling around with the code and found that when we remove the username from the keys array in App.js, it works fine. but adding it back recreates the problem.
If all other keys in the array(other than username) work without issue, then there's a high possibility that the API schema has been changed(eg. username may have been removed or renamed).
@Sam-Takahashi you made a modification to the schema back during the profile update, right? There might a possibility that the issue came from there. Could you have a look at it?
The schema definitely has been changed.

notice there isn't username field in the response.
We(Lydia and I) modified the models/ProfilePage.js, but we have not modified the Post schema, which is causing this error.

A workaround will be needed for the username, in that case, because having the user's id would make more sense when making relationships. Also, I've been working on the upvotes system which now relies on the same relationships. The new json object for the post will be something like this:
post:[
post_data,
user:[
user_data
],
votes:[
an array of votes on the post
]
]
Before working on a workaround, shouldn't we investigate how the schema was changed? All the dummy data appears to have been wiped out as well, what was the reason for this?
@Sam-Takahashi could take a look at the changes you made from the previous update? Far as I remember, that was the last time server files were changed. Maybe we missed out on something there.
I've been working on the upvotes system which now relies on the same relationships.
I went over the changes I made, and there shouldn't be an issue if the Posts schema contains the username value.
I hate to point the finger, but @vikashjajra mentioned he's working on the upvote system. The current schema no longer contains a username and instead, it now contains a votes array. I may be wrong in assuming this but perhaps @vikashjajra modified it for the upvote system? https://github.com/vinsdragonis/Project-Nexus/issues/93#issuecomment-1230223201
Forgive me if I'm wrong.
I guess we need to be more careful making changes to the database hosted from now. Better make a clone of the DB and locally test it. Regardless of where this issue started, we can't afford to test anything on live data ever again.
On changing the mongo URL on the server to a localhost version, it should automatically create a new local version of the DB after starting the server. Once tested, please share a screenshot of the working app to ensure everything works fine locally. That way, we can confirm that it can work the same way when hosted.
I've been working on the upvotes system which now relies on the same relationships.
I went over the changes I made, and there shouldn't be an issue if the Posts schema contains the
usernamevalue.I hate to point the finger, but @vikashjajra mentioned he's working on the upvote system. The current schema no longer contains a
usernameand instead, it now contains avotesarray. I may be wrong in assuming this but perhaps @vikashjajra modified it for the upvote system? https://github.com/vinsdragonis/Project-Nexus/issues/93#issuecomment-1230223201 Forgive me if I'm wrong.
Thanks for pointing this. you're absolutely right my friend. I didn't realise I was working on the hosted mongoURL instead of the local one.It is my fault.
@vikashjajra that is fine. Fortunately, the data was just to fill up space though it took some effort to put up. Please be careful about it next time, we don't want that to happen in a production environment.
@vikashjajra that is fine. Fortunately, the data was just to fill up space though it took some effort to put up. Please be careful about it next time, we don't want that to happen in a production environment.
I will be more cautious.