Several fixes to RSS component and object lists

[kshepherd]

References

• Fixes The info in the RSS feed are not the same as on the homepage #4172

Description

The RSS button was not keeping track of sort options in any case (including search result pages). It was instead using default pagination.

This PR adds a new showRSS input for object collection, object list, and pagination components.

The input takes type SortOptions | boolean, allowing the syndication feed button to be simply enabled or disabled with a boolean, or have the parent pagination sortOptions overridden with a custom sortOptions (for example, we can set "date descending" sort options for an RSS button in the top level community component, even though the pagination for top level community results is "title ascending").

If a null, undefined or otherwise invalid or incomplete sortOptions is passed, the pagination component will pass its own sortOptions to the RSS button.

The default value for this input in all implementing components is false.
Search results component and Recent Items components both set this to true.

The component will now update the RSS link on a change to the sort options in a search page, and uses the correct pagination/sort options for the calling component (recent items, search, etc), or the custom sort options for e.g. top-level community page

• RSS button displayed on search result pages with correct pagination matching the search
• RSS button displayed on Recent Items component with correct pagination
• RSS button displayed on Top Level community component, with CUSTOM sort options of date accessioned descending
• RSS button NOT displayed in other components by default
• RSS component tracks sort option changes on search result pages

Rather than my earlier work which moved the RSS button, this will now show 2 buttons on the homepage by default. I am happy to remove the recent submissions one in this PR so there is a less obvious change.
I tend to like leaving it, because it means that even if top-level community is further customised or disabled by a repository, there is still a relevant, in-context syndication feed for the recent submissions component.

(consider that #4172 says "the info are not the same as on the homepage" -- it refers to the recent submissions here, not community names!)

Instructions for Reviewers

• Without this PR applied, note the difference in Recent Items and Search Results in the displayed UI lists, vs the RSS feeds when the button is clicked

• In search pages, note that the sort is still Title Ascending after the search sort options are changed

• With this PR applied, try the same tests. The button on the homepage will now be displayed near Recent Submissions and the top-level community list.

Note: The additional inputs to object list, object collection components were a bigger change than I initially anticipated, and I don't think it should be breaking to any custom themes as there is a safe default set everywhere, but I want to note it just in case this moves it up from being a very simple bug fix.

TODO: If this approach is generally approved, I will write unit tests to ensure expected sort options in the ds-rss component

I may need to write some additional tests.

Checklist

This checklist provides a reminder of what we are going to look for when reviewing your PR. You do not need to complete this checklist prior creating your PR (draft PRs are always welcome).
However, reviewers may request that you complete any actions in this list if you have not done so. If you are unsure about an item in the checklist, don't hesitate to ask. We're here to help!

• My PR is created against the main branch of code (unless it is a backport or is fixing an issue specific to an older branch).
• My PR is small in size (e.g. less than 1,000 lines of code, not including comments & specs/tests), or I have provided reasons as to why that's not possible.
• My PR passes ESLint validation using npm run lint
• My PR doesn't introduce circular dependencies (verified via npm run check-circ-deps)
• My PR includes TypeDoc comments for all new (or modified) public methods and classes. It also includes TypeDoc for large or complex private methods.
• My PR passes all specs/tests and includes new/updated specs or tests based on the Code Testing Guide.
• My PR aligns with Accessibility guidelines if it makes changes to the user interface.
• My PR uses i18n (internationalization) keys instead of hardcoded English text, to allow for translations.
• My PR includes details on how to test it. I've provided clear instructions to reviewers on how to successfully test this fix or feature.
• If my PR includes new features or configurations, I've provided basic technical documentation in the PR itself.
• If my PR fixes an issue ticket, I've linked them together.

[kshepherd]

@tdonohue i still have some new tests to write, but requesting an early review from you now to get your input on my revised approach - this will allow the button to still be displayed in top level comm list, but also keeps my earlier work to track parent pagination sort options.

If you generally approve, I'll start on tests and I'd appreciate review by another angular dev too, to check my implementation

[tdonohue]

@kshepherd : Gave this a test & review today. Overall, I like the approach you've taken, and the code looks good (I would appreciate it if @alexandrevryghem could give it a quick look too).

I can also verify now that the RSS button is working properly & that it's behavior changes to match the current sort order or number of results. I like that it also now appears for search results too, so that you can "subscribe" to a search via RSS.

But, I noticed a few things that I'd like us to consider fixing/changing:

1. I don't like the fact that two RSS buttons now appear on the homepage when recent submissions are enabled. They are simply duplicative as they always will have the same sort order & number of results (there's no ability to reorder the homepage). I'd be OK with the button appearing in either location, but not both.
   • One option here is to just document that the RSS button only appears on the homepage if recent submissions are enabled (and only have it appear there).
2. I noticed with this PR that the RSS button has accidentally disappeared from all Community/Collection pages (on the default "Search" tab). It's appearing on those pages on the demo site, but is gone when I use this PR.

Beyond that, everything else looks good to me.

[kshepherd]

thanks @tdonohue !

1. I'm happy with either approach, too, and I understand keeping it where it was (and disabling from recent submission by default, but documenting how it enable it) would be less disruptive or surprising to users. One day we might think about writing a tiny "recent submissions rss" component so the button can be shown anyway with the right pagination and context, but without the baggage of an actual item list. That way it can appear anywhere in the layout, easily.
   So for now I'll push a change to remove from recent submissions by default, and we'll just have the one button displayed in the same position as 8.x

2. The default for showRSS is false, so I must have missed that these Collection and Community page components need to set it to true. It's possible that I should actually set the default to true... that probably will match previous behaviour closer.

The button was showing for search results previously, iirc, (that's actually how this issue got introduced I think) but it wasn't tracking changes to the sort options fully.

[kshepherd]

@tdonohue button should now display on collection and community pages - the enableRSS route data needed to be moved to a different routing module as of v9

I also removed the ds-rss from the recent items template, so it won't display there.

After noticing the name of that variable more (which is a more broad enable/disable based on route, rather than something overridden in the component inputs themselves), I wondered if my showRSS input would be better named rssSort or rssSortOverride or something... (though it can act as a way to explicitly disable the RSS button from a comp/list even if the route enables it through enableRSS, so perhaps it's OK with sufficient documentation)

[tdonohue]

👍 Thanks @kshepherd ! This now looks good to me & works well. Regarding your question about the showRSS input, I don't mind the current name because it is deciding which components are going to show this RSS icon.

I did find one tiny thing below that might need cleanup before merger.

[tdonohue]

Thanks @kshepherd ! Looks good!