Remove the Tooltip Message After Successful Cover Image Loading

[nihal467]

Describe the bug

When the cover image is fully loaded, the tooltip message that states, "It could take a while to see the updated cover image," should be automatically removed.

To Reproduce
Steps to reproduce the behavior:

1. Go to facility tab
2. Click on any facility card
3. upload a cover image to the facility
4. See error

Expected behavior

• The tooltip message should be visible only while the cover image is loading. Once the image has fully loaded, the tooltip should be automatically removed.

Note: currently, if we manually refresh the page, the text will disappear

Screenshots

[Jacobjeevan]

@nihal467 Can you assign this issue to me? Thx.

[rithviknishad]

@Jacobjeevan

Let's clear the browser cache using vary header method mentioned in this https://www.fastly.com/blog/clearing-cache-browser. We can perform the cache invalidation once the cover image upload has been completed. This would ensure the latest image is rendered.

cc: @sainak

[Jacobjeevan]

@rithviknishad Hmm, since useQuery doesn't support a header parameter, I'd either need to replace it with a fetch outside or modify RequestOptions interface and request function to support header property (preferring the former since it touches less code). Does that sound right, or is there an alternative option?

[rithviknishad]

you'll have to use fetch directly to achieve this since the image url is not a defined api route right? useQuery/request requires an API route to be defined, and the image url is not an API route.

[rithviknishad]

The additional headers on request options however is useful. Can be done in a separate issue/PR.

[Jacobjeevan]

you'll have to use fetch directly to achieve this since the image url is not a defined api route right? useQuery/request requires an API route to be defined, and the image url is not an API route.

@rithviknishad Oh, I meant moving out the facilityData useQuery to a fetch req (since cover image url is part of that object). Hmm, as for fetching the image url directly, that would require modifications on the backend, right?

[rithviknishad]

No, you just need to simply send a fetch request to the signed URL of the image with that vary header, so that browser would invalidate it's cache. Therefore leading to the image component to render the new image as the new image is fetched instead of the old cached one.

Nothing to do with calling any APIs.

[rithviknishad]

Read: https://www.fastly.com/blog/clearing-cache-browser

[Jacobjeevan]

No, you just need to simply send a fetch request to the signed URL of the image with that vary header, so that browser would invalidate it's cache. Therefore leading to the image component to render the new image as the new image is fetched instead of the old cached one.

Nothing to do with calling any APIs.

(1) Couldn't use the fetch + vary method as the HeadersInit type doesn't support it

Type '{ "Forced-Revalidate": number; }' is not assignable to type 'HeadersInit | undefined'.

(2) Tried fetch + cache:reload instead. Checking the network tab, it does pull the new version of the image, however I had to append timestamp to have it reflect on page (I tried changing image src directly using getElementById, but that didn't reflect on screen). fetchImage is called on save of the Edit Cover Image Modal/Popup.

It doesn't seem to update the cache though, since the change doesn't persist across page reload.

https://stackoverflow.com/questions/1077041/refresh-image-with-a-new-one-at-the-same-url/22429796#22429796 mentions few other solutions, including just using timestamp on img src directly, however that would mean storing multiple copies of the same image on cache.

[rithviknishad]

I don't see any type errors in Force-Revalidate: random number as string method.

Numbers can't be set as header value. However, number as strings can be.

[Jacobjeevan]

I don't see any type errors in Force-Revalidate: random number as string method.

Numbers can't be set as header value. However, number as strings can be.

Ah ok, thanks!

Wouldn't this require Vary: Forced-Revalidate on S3? Anyways, I tried with Forced-Revalidate: 1. But, I'm getting the same result as (2) in my reply above; new image is pulled by the fetch req in the network tab/dev tools, but only reflected on screen if I append a timestamp to the url. Cache doesn't seem to be updated as the change doesn't persist across page reload.

[rithviknishad]

Did you try passing a key prop to the img. component?

[Jacobjeevan]

Did you try passing a key prop to the img. component?

Never mind, I cleared my browser cache/restarted the dev server and it's working (persists across page reload). Only other issue is the change not reflecting on FacilityCard (if the user navigates thru back button or breadcrumb menu instead of reloading).

[rithviknishad]

Hey, could you push the current changes?

[Jacobjeevan]

Hey, could you push the current changes?

Done 👍