Fix/432 Dataset view metadata missing fields

[g-saracca]

What this PR does / why we need it:
This PR not only fix that Geo Bounding Box fields are not displayed, I have found a bigger issue.
The formatting of the metadata fields was not being correct when a dataset had metadata in addition to the citation block.

<DatasetMetadataFields /> component was being used in the Metadata tab and also in the Summary description.
In both places, the display format information was obtained from a context provider by block name (MetadataBlockInfoProvider), but the problem arose when there was another block other than Citation, this context changed the new information to the requested block name and the display format information was mixed up, causing the blocks that needed the Citation information to be getting information from another block.

Which issue(s) this PR closes:

Closes #432

Special notes for your reviewer:
N/A

Suggestions on how to test this:
Create a Collection with more than one metadata block.
Then create a dataset filling fields from all the blocks.
Navigate to the dataset page view in the SPA and check that summary description and fields in every block of the metadata tab are being displayed and formatted correctly.

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

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

Additional documentation:
N/A

[coveralls]

coverage: 97.761% (+0.08%) from 97.682%
when pulling 378d42b on fix/432-dataset-view-metadata-missing-fields
into 91b2db6 on develop.

[ekraffmiller]

@GermanSaracca this works very well, I just have a question about using a custom hook rather than a shared context for the metadata block info. With the custom hook, the same data is retrieved multiple times. I can see how it is needed twice, once for summary and once for the metadata tab, but when a look at the Chrome Network tab, I can see that each metadata block is retrieved four times, I'm not sure why.
Also, it seem like the problem with the context is that it is only is storing state for one metadata block. If was updated to contain the info for all the metadata blocks, then I think it could be shared between the summary and the metadata tab without a problem. Maybe there are other advantages to using a custom hook that make it a better solution, despite the multiple API calls?

Here's an example of the multiple network calls, from the View Dataset page -

[g-saracca]

Hi @ekraffmiller thanks for the feedback

About the multiple fetch requests: I think what you see in the Chrome Network tab is due to <React.StrictMode> mounting, unmounting and mounting again the components (this only happen in dev mode, not when building the app). You can comment out that wrapper from src/index.tsx to check if that problem goes away.
Please let me know about this.

About keeping a shared context:
I understand that with a shared context we could avoid fetching the same data again, but we will have to handle different scenarios like checking if the same block name is already being fetched from another component, managing different loading states for each block, see if that block name is already fetched and stored in context memory and I'm not quite sure if we should use a context for that (I'm not a fan of contexts as if the state of the context changes, all the components it wraps will re-render).
There are specific libraries like RTK (Redux Toolkit) that makes it easy to fetch data, manage load states, errors, caching, etc, but of course it will take work to set up most of the tests and follow the project architecture as well.

Anyway, I can try to achieve that with a shared context if you think that is a better approach, I like challenges ☺️ but perhaps the solution I find will not be too scalable.

[ekraffmiller]

Ok, I forgot about StrictMode, thanks for reminding me! When I remove it, the calls happen twice, which I think is a good tradeoff for avoiding the complications you mentioned.
Thanks for the explanation about context, I'm still learning the pros and cons of these different solutions. 😊

[ekraffmiller]

Looks good to me!

[GPortas]

Looks good!