Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
subcommunities: improve search page #1242
base: master
Are you sure you want to change the base?
subcommunities: improve search page #1242
Changes from 4 commits
9967c36
7aca22e
eaf7d63
6aef16e
3061252
e118fba
4fa7155
d535752
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
The front-page could reuse this "All / My communities" button. Is it worth moving it to its own component and re-using it? @ptamarit @0einstein0
I've found this to be a bit more complicated since it changes the
apiConfig
entirelyThere 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 think that not showing the buttons to unauthenticated users (as currently done in the front page) would be better. It's more of a convenience than a crucial functionality; if a community owner happens to be logged out, they will still be able to find their community via text search.
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.
That's a good point. Regarding the question "should we make this a reusable component and use it in the frontpage", wdyt?
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.
Yes, right now, this is mostly the same as CommunitySelectionSearch in invenio-rdm-records.
It could go to
react-invenio-forms
and be used in all 3 places: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 don't think this component to filter between "All" or "My communities" should be in
react-invenio-forms
. It's too specific for communities. To be moved even higher in the modules, it had to be more abstract.I added a reusable component
CommunitiesStatusFilter
ininvenio_communities/community/searchComponents
and used it in the 3 places you mentioned.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.
This file is almost the same as https://github.com/inveniosoftware/invenio-requests/blob/master/invenio_requests/assets/semantic-ui/js/invenio_requests/search/RequestsResults.js (just renamed it). That makes me think this can be moved to a higher module so both requests and communities can reuse it.
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.
Maybe also in
react-invenio-forms
?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.
this is a search aware component, we should move it to invenio-search-ui?
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.
Exactly, I was just messaging Pablo about this. +1 on moving it to
invenio-search-ui
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.
After the discussion, I moved it to a reusable component named
invenio_search_ui/components/SearchResultsBox
. Not the best name but I'm open to changing it to anything else 😄However, let's align IRL whether this is the right place / way or not . Ping @ntarocco @ptamarit @kpsherva
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.
The idea was to create a base package, similar to invenio-base for Python code, that serves as a catalog of components. This package should remain stateless, without any specific features or logic, making it a simple dependency that can be included in other modules.
While I understand the rationale behind associating a component that displays search results with invenio-search-ui, I believe that it doesn't align with the intended purpose of the base package.
The base package is meant to be a neutral catalog, and incorporating such a component into invenio-search-ui would go against these criteria.
I am sure that we will find a case where we will need that component in a place where we don't depend on invenio-search-ui.
Happy to hear/read counterarguments.