Prevent duplicating .ellipsis-y-* CSS classes into every component stylesheet

[saschaszott]

References

• Fixes .ellipsis-y-* classes in _mixins.scss are duplicated into every component stylesheet (bloats SSR HTML and JS bundles) #6270
• Follow-up to [DSpace-CRIS] Porting of authority framework functionalities (Frontend) #4956 (commit 8c073ff)

Description

_mixins.scss is prepended to every component SCSS file by sass-resources-loader, so the @for loop that generates .ellipsis-y-1 … .ellipsis-y-10 is compiled into the styles of every DSpace Angular component. This PR removes that loop and defines the two required CSS classes that are actually used locally in metadata-link-view-popover.component.scss.

Instructions for Reviewers

Run DSpace frontend with a production build (so that SSR is enabled). Open the landing page of an DSpace item, e.g., a publication or project.

Before applying the change: The HTML code contains 50+ duplicated rules .ellipsis-y-1 … .ellipsis-y-10 (almost 10% of the size of the HTML file). Additionally, you'll find 500+ component-scoped copies in dist/browser/*.js and 1000+ in dist/server/*.js.

After applying the change: restart the Angular fronend (SSR cache is empty) and reload the HTML landing page. The duplicated CSS classes in the HTML source are no longer present.

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 follows all coding best practices based on the Code Conventions Guide
• 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 libraries/dependencies (in package.json), I've made sure their licenses align with the DSpace BSD License based on the Licensing of Contributions documentation.
• 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.

[alanorth]

Thanks @saschaszott. You're right, there are 58 on sandbox.dspace.org right now.

I tested this and these class definitions are no longer present on pages that don't use them (currently only the ds-metadata-link-view-popover component).

[saschaszott]

@alanorth , thanks for reviewing this. Should we backport it to DSpace 10.2?

[alanorth]

Apologies @saschaszott, yes this should be ported to DSpace 10.2. I looked briefly and didn't see this code on the dspace-10.1 tag, but I realize I missed it because I grepped for "ellipsys" instead of "ellipsis". Sorry!

I'm not sure if we can use the automatic porting bot now that this has been merged. If you port it I will merge it. Thank you.

[alanorth]

@saschaszott I've ported it to dspace-10_x in #6273.

Thanks!