-
Notifications
You must be signed in to change notification settings - Fork 21
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
issue 488 #495
issue 488 #495
Conversation
👷 Deploy request for upswyng pending review. 🔨 Explore the source changes: 84da87e |
It looks like the param was actually already formated to work with getByStub so my parser wasn't necessary anyway. Happy to add getByName as well if we want to change the target routes on the front end, but for now I'll just fix it to work with getByStub. |
Ya I think it makes sense to have it work with edit: Although take a look at a 2nd approach I added below 😅 |
}; | ||
|
||
const categories = await getCategories(); | ||
const resourceIdsFromCategories = [ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm conflicted about using the IDs that we receive from the category model. In the end, I think we'd rather query the resources model only once based on the provided filters.
So instead of:
- getting categories, which queries the DB for categories and then queries it again for resources IDs belonging to that category
- crawling resources for those having an ID that matches the provided
id
filter
We'd instead:
- get categories, which only queries the DB for categories
- get resources that is one query looking for resources that belong to that category and also have an ID in the provided
id
filter
What do you think about:
- creating a new method in the Category model called
getByStubs
which is similar togetByStub
. This would accept an array of stubs and only include subcategories (without populating resources). - adding a new method to the Resource model that accepts an array of sub categories and resource IDs and finds resources based on both parameters. It'd be similar to getByResourceIds with sub-categories added to the mix.
Thoughts?
I think this approach is looking good! Posted another suggested approach to take a look at. I'm ok with using what you have for this work and following up later if you like. One other thing to note is that we should add the new category to our endpoint documentation. You could add a new Looking noice! |
This PR closes #488
How does this PR make you feel? 🔗