[Content] Improve image thumbnails

[finnar-bin]

Show the appropriate thumbnail for non-image files
Resolves #3206

[agalin920]

In what cases will it not? Its an RTK query hook, that data will always be present (fetched or cached)

[finnar-bin]

This was added to address @shrunyan 's concern in case the cache may have not have been updated

[agalin920]

Looking at the thread comment you are correcting the assumption that we do in fact make api call and hydrate the media on every load. Was there an additional discussion im not aware of? Im trying to understand in what real world cases this code path will go down. Bigger concern, what if the file has been deleted? Wouldn't this case cause the table cell to make a call every single time?

[finnar-bin]

Stuart and I had a discussion about this last week on a call. If I remember correctly, I think the reason was that it's just a backup in case the cache doesn't have it yet, since in the future what if we decide to limit the response of the api that fetches all the media files then there's a possibility that the file is missing in the cache.

Regarding the concern about a file being deleted, that's actually a good catch. I'll look into that today and see what the behavior is.

[finnar-bin]

@agalin920 so based on my testing the ImageCell does end up triggering the getFile rtk query every time it's rendered (scrolled in and out of view for example) when the file has been deleted. I can't think of any other way to prevent this aside from having a state on the parent that stores all image zuids with deleted files but I think that's just way too much.

[shrunyan]

Wouldn't the record in the local cache have a deleted_at value? That would then inform us the item is deleted. We could not make the API call and display an experience which indicates the fact the image is delete.

[finnar-bin]

@shrunyan there's a deleted_at field but as soon as a file is deleted and rtk query's cache gets invalidated and therefore has to do a get /bin/1-xxxx-xxxx/files to update the cache, the deleted file no longer gets returned in the response. Similarly, doing a get /file/3-xxxx-xxxx to fetch the file, returns a 404 since the file has already been deleted.

The downside to the code that I added above which @agalin920 is raising is that whenever a user is scrolling and a field with a media item that has been deleted is rendered, it will always attempt to do a get /file/3-xxxx-xxxx and will always return a 404, it doesn't loop per se but it does do the api call everytime that item gets rendered to the virtualized table.

[shrunyan]

With deleted files being requested every time they are rendered I'm not sure it matters that much. As it is about just as chatty with the API as files which are not deleted, those records have to fetched as well. A bit more as the user could scroll away and back which would then cause a network request versus pulling it from cache(as you stated it wouldn't be present due to it being deleted and purged from the local rtk query cache). The ratio of deleted images to non-deleted images I would have to imagine is very low. Additionally there could be an argument to be made about wanting to express the fact the associated image to the content record is deleted. Otherwise how else would a user know that. All-in-all I am not sure I see the re-fetching of referenced images which have been deleted as something we should avoid.

Towards @agalin920 primary point around what is the purpose of this check, as the assumption is the data should be present either from network or cache. I'm assuming that is in reference to the isFetchingAllMediaFiles call in this same component. That call seems to aggressive to me. If the component is provided a parameter of the media ZUID why are we not doing a single media file check against cache and then network? To jump ahead of a response of "it would cause to many requests" is that what the all media fetch at app load covers?

[Copilot]

Pull Request Overview

This PR improves the image thumbnail display by introducing file data lookup logic and using a dedicated preview component for non-image files. Key changes include:

• Updating ImageCell to query file details via the media manager and render a FileTypePreview.
• Simplifying the image URL extraction logic in ItemList.
• Correcting the ecoId property to ecoID in the Favicon component.

Reviewed Changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
src/apps/content-editor/src/app/views/ItemList/TableCells/ImageCell.tsx	Implements file data retrieval and conditional rendering for image/non-image thumbnails.
src/apps/content-editor/src/app/views/ItemList/index.tsx	Simplifies image URL extraction by removing legacy resolution logic.
src/shell/components/Favicon/index.tsx	Updates property name for consistency with store types.

Comments suppressed due to low confidence (1)

src/apps/content-editor/src/app/views/ItemList/TableCells/ImageCell.tsx:96

• Rendering FileTypePreview without ensuring that fileData is present may lead to UI issues. Consider adding a conditional check to render a placeholder or skeleton until fileData is available.

<FileTypePreview isMediaThumbnail src={fileData?.url} filename={fileData?.filename} updatedAt={fileData?.updated_at} />