Skip to content
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

Open
wants to merge 8 commits into
base: master
Choose a base branch
from

Conversation

alejandromumo
Copy link
Member

@alejandromumo alejandromumo commented Oct 23, 2024

closes zenodo/zenodo-rdm#1015

Anonymous user
image

Authenticated user
image

** Smaller screens ªª
image

@@ -0,0 +1,75 @@
// This file is part of Invenio
Copy link
Member Author

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.

Copy link
Member

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?

Copy link
Contributor

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?

Copy link
Member Author

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?

Exactly, I was just messaging Pablo about this. +1 on moving it to invenio-search-ui

Copy link
Member Author

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

Copy link
Contributor

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.

Comment on lines 108 to 129
<Menu.Item
as="button"
role="tab"
id="all-communities-tab"
aria-selected={selectedAppId === allCommunities.appId}
aria-controls={allCommunities.appId}
name="All"
active={selectedAppId === allCommunities.appId}
onClick={() =>
this.setState({
selectedConfig: allCommunities,
})
}
>
{i18next.t("All")}
</Menu.Item>
<Menu.Item
as="button"
role="tab"
id="my-communities-tab"
aria-selected={selectedAppId === myCommunities.appId}
aria-controls={myCommunities.appId}
Copy link
Member Author

@alejandromumo alejandromumo Oct 23, 2024

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 entirely

Copy link
Member

@ptamarit ptamarit Oct 24, 2024

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.

Copy link
Member Author

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?

Copy link
Member

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:

  • The community front page
  • The subcommunities search
  • The deposit form community selection

Copy link
Member Author

@alejandromumo alejandromumo Oct 24, 2024

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 in invenio_communities/community/searchComponents and used it in the 3 places you mentioned.

// eslint-disable-next-line react/no-deprecated
ReactDOM.render(
<Container>
<CommunitySelectionSearch
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had to create a component due to the changes of config, based on the selection of "All" or "My communities". I could not connect the config with the component returned by createSearchAppInit, so I created a component that instantiates the search application.

Comment on lines 31 to 38
export const overriddenComponents = {
[`BucketAggregation.element`]: ContribBucketAggregationElement,
[`BucketAggregationValues.element`]: ContribBucketAggregationValuesElement,
[`SearchApp.facets`]: ContribSearchAppFacetsWithConfig,
[`ResultsList.item`]: CommunityItem,
[`ResultsGrid.item`]: ResultsGridItemTemplate,
[`SearchBar.element`]: CommunitiesSearchBarElement,
[`SearchApp.results`]: SubcommunityResults,
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does it make sense to have the overridden components defined outside the element? Since this is now a "dedicated" search component for subcommunities, perhaps this could be defined in the component itself

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we move the component to react-invenio-forms, we should use props rather than overrideable.

Copy link
Contributor

@kpsherva kpsherva Oct 24, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Screenshot 2024-10-24 at 17 15 49

maybe it makes sense to have just one in search ui?
the overridable component exposed from there already has the appName prop ready for you to use

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure I understood what using props means in this context. But let's have a discussion IRL with @ntarocco and @kpsherva to align

Copy link
Member

@ptamarit ptamarit left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewed with @ntarocco

Comment on lines 108 to 129
<Menu.Item
as="button"
role="tab"
id="all-communities-tab"
aria-selected={selectedAppId === allCommunities.appId}
aria-controls={allCommunities.appId}
name="All"
active={selectedAppId === allCommunities.appId}
onClick={() =>
this.setState({
selectedConfig: allCommunities,
})
}
>
{i18next.t("All")}
</Menu.Item>
<Menu.Item
as="button"
role="tab"
id="my-communities-tab"
aria-selected={selectedAppId === myCommunities.appId}
aria-controls={myCommunities.appId}
Copy link
Member

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:

  • The community front page
  • The subcommunities search
  • The deposit form community selection

@@ -0,0 +1,75 @@
// This file is part of Invenio
Copy link
Member

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?

Comment on lines 31 to 38
export const overriddenComponents = {
[`BucketAggregation.element`]: ContribBucketAggregationElement,
[`BucketAggregationValues.element`]: ContribBucketAggregationValuesElement,
[`SearchApp.facets`]: ContribSearchAppFacetsWithConfig,
[`ResultsList.item`]: CommunityItem,
[`ResultsGrid.item`]: ResultsGridItemTemplate,
[`SearchBar.element`]: CommunitiesSearchBarElement,
[`SearchApp.results`]: SubcommunityResults,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we move the component to react-invenio-forms, we should use props rather than overrideable.

<CommunitySelectionSearch
overriddenComponents={overriddenComponents}
config={config}
userAnonymous={userAnonymous}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For consistency, we can use myCommunitiesEnabled as done in zenodo/zenodo-rdm#1031

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I renamed myCommunitiesEnabled to communitiesStatusFilterEnabled since there's a reusable component CommunitiesStatusFilter to toggle between "All" and "My communities".

But followed the same pattern, looks good 😄

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

subcommunities page: show "My communities" and "All communities" buttons to filter
4 participants