267 add url test to resources

[sorochak]

This PR solves issue: #267

• added a debounce util function to debounce HTTP requests
• validateURL was defined in more than one place - removed a definition and imported from validate.js
• added checkURLActive firebase function
• implemented checkURLActive call in Resources component, to notify users if URL is not active

In order to test this locally you need to run the firebase emulator. Instructions here:

metadata-entry-form/README.md

Line 20 in 1bbb633

### Running the Firebase emulator

Note: checkURLActive is not yet deployed to Firebase.

TO DO:

• deploy checkURLActive when PR approved.

[github-actions]

Visit the preview URL for this PR (updated for commit 2c97aba):

https://cioos-metadata-form--pr306-267-add-url-test-to-mo9x8ly3.web.app

_{(expires Sun, 25 Feb 2024 21:49:58 GMT)}

_{🔥 via Firebase Hosting GitHub Action 🌎}

_{Sign: 57eda2a7622dc877ccadb675a0532261c52b09fd}

[fostermh]

if checkURLActive is a new firebase cloud function then you can deploy it to production now, assuming it doesn't cause an error. it will only be used by the test deployments until this pr is merged into main so will not break production.

[JessyBarrette]

For some reasons, I can see the http/https check is working however, modifying the url to some wrong ones doesn't seem to trigger the second check.

Example: https://cioos-metadata-form--pr306-267-add-url-test-to-mo9x8ly3.web.app/#/en/pacific/hM2aN3v9MzZ6J4KGMOEW2s9gidj2/-MtLHJgz141q5Fb27oP-

If I remove some letters from the url which returns a 400 the check seems to still return valid:

https://data.cioospacific.ca/erddap/tabledap/IOS_CTD_Moorings.ht

[sorochak]

@JessyBarrette if you were testing this via the preview URL and not running the firebase emulator locally, the new checkURLActive firebase cloud function wouldn't work.

As per @fostermh comment above, I have just deployed checkURLActive to the cloud, and so now it should work via the preview URL.

[JessyBarrette]

Oh sorry yes I can see it working now :)

I'm wondering if it would be worth to bring a message to the Submit tab whenever a link isn't working.

[Br-Johnson]

Looks great to me.

[JessyBarrette]

I'm wondering if it would be worth to bring a message to the Submit tab whenever a link isn't working.

We can create a new issue for that if that is going over the present issue

[sorochak]

@JessyBarrette I can add a message to the submit tab when a link isn't working

[JessyBarrette]

Awesome thanks @sorochak Once this is done I can approve all that :) nice work

[fostermh]

when we discussed this I was thinking of a status pill that would show if the link was resolvable or not. something similar to this pr for doi status #283

It's ok if we prefer this interface but it would be nice to be consistent across the form

[sorochak]

What interface do we want to be consistent with?

currently this PR displays a notice if the link is unresolvable:

[sorochak]

@JessyBarrette @timvdstap this PR is ready (again) for review.

[JessyBarrette]

This is all looking great to me!

I guess we could eventually color code the ERROR anr WARNING sections of the submit page. But this should be an another issue first.

Well done!

[JessyBarrette]

I think it would highlight the difference between the two sections within the submit page. *Jessy Barrette M.Sc.* *Marine Data and Instrumentation Specialist* Hakai Institute <https://www.hakai.org/> | CIOOS Pacific <https://cioospacific.ca/> | CIOOS <https://cioos.ca/> | ***@***.*** | (C) (250) 208-7806 Le ven. 26 janv. 2024 à 17:13, Austen Sorochak ***@***.***> a écrit :

…

I had considered making the Error and Warning headings red? — Reply to this email directly, view it on GitHub <#306 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHICYOL7UNOUQTWJRRD2NQDYQQTBJAVCNFSM6AAAAABB6TIW4KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMJSG43DINBYG4> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[timvdstap]

I think it looks good and seems to work fine! I agree with Jessy that we could perhaps at a later stage revisit the color coding of the warning messages (i.e. even if it says "URL is not active", I think it'd be nice if this shows up in red). Something to perhaps address later :-)