261 - Add File Citation to File Page

[MellyGray]

What this PR does / why we need it:

This PR adds the File Citation section to the UI of the File Page.

Which issue(s) this PR closes:

• Closes Add the FileCitation section to the File Page #261

Special notes for your reviewer:

I refactored some components related to the citation to rehuse them in the FileCitation component

The citation boxes won't look as in the mock, with the coloured background because in the SPA the dataset citation box only has the border coloured, so I did the same with the File Citation box.

Suggestions on how to test this:

1. Install the necessary dependencies using npm install.
2. Build the design system with cd packages/design-system && npm run build.
3. Navigate back to the root directory with cd ../../.
4. Start Storybook with npm run storybook.
5. Visit the File Page in the Storybook
6. For detailed stories of the FileCitation component you can go to the FileCitation section of the storybook

Does this PR introduce a user interface change? If mockups are available, please link/include them here:

Is there a release notes update needed for this change?:

No

[coveralls]

coverage: 97.822% (-0.03%) from 97.854%
when pulling 30ae03e on feature/261-file-citation-ui
into b5f65e2 on feature/249-boilerplate-file-page.

[GPortas]

In general it looks good.

I have found a detail that I believe is an error in the composition of the file citation block text.

I don't see anything similar in JSF

[GPortas]

I think here is where the string is composed incorrectly. (${fileName} [fileName]`)

[MellyGray]

This is how I see the files in JSF, with the [fileName] part. If you look at the DataCitation.java in the dataverse repo, that part is added if there is no global identifier

In any case, I was assuming that the citation was coming from the API, as in the Dataset page. So this (${fileName} [fileName])` logic only applies to the Stoybook, then I can change it to a different string if we don't like the one with the [fileName]

Please, let me know if my assumption was correct and the citation is coming in the API payload as it does in the dataset payload, otherwise I have to apply that logic to the SPA

[GPortas]

Nice extraction

[jggautier]

@GPortas, about the composition of the file citation block text, could you see what the citation looks like when the file is given a persistent ID?

All files in Demo Dataverse, including the file in your "JSF" screenshot, are given a persistent ID.

But for files that aren't given persistent IDs, such as https://dataverse.harvard.edu/file.xhtml?fileId=8079268&version=1.0, it looks like the file's citation block text composition is the same as your first screenshot with the red circle.

This difference is citation composition is discussed in IQSS/dataverse#4777 and it was done intentionally. The conversation in the GitHub issue is a bit long but it ends with Phil's comment at IQSS/dataverse#4777 (comment).

[GPortas]

Thank you @jggautier,

Then we have to compose the citation text by choosing one of the two composing options depending on whether the file has a persistent ID or not.

@MellyGray I think we should add this distinction in the logic in this PR.

[GPortas]

@MellyGray is right. The citation string must come from the js-dataverse package, as for datasets, so the way it is composed must be opaque to the SPA. This is something to address in the upcoming API and js-dataverse issues and not here.

[ekraffmiller]

@MellyGray can you resolve the conflicts in this PR?

[ekraffmiller]

looks good!