Skip to content

[Content] Improve image thumbnails #3224

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 17 commits into
base: dev
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
17 commits
Select commit Hold shift + click to select a range
9189516
Refactor ImageCell component to use FileTypePreview and improve file …
finnar-bin Feb 14, 2025
264d15e
Add skeleton loader to ImageCell component for improved loading state
finnar-bin Feb 14, 2025
3d2cb3b
Merge branch 'dev' into fix/3206-update-thumbnail-component
finnar-bin Feb 19, 2025
b57b71f
Merge branch 'dev' into fix/3206-update-thumbnail-component
finnar-bin Feb 28, 2025
79ddf64
Use cached media files to get file data
finnar-bin Feb 28, 2025
5bcb0c8
Fix issue where ecoID is incorrect
finnar-bin Feb 28, 2025
ffa91b8
Merge branch 'dev' into fix/3206-update-thumbnail-component
finnar-bin Mar 11, 2025
67aa113
Attempt to search for file data if cache doesn't have the data for it
finnar-bin Mar 11, 2025
c48c421
Merge branch 'dev' into fix/3206-update-thumbnail-component
finnar-bin Mar 19, 2025
6393ccd
Merge branch 'dev' into fix/3206-update-thumbnail-component
finnar-bin Mar 20, 2025
2b29590
Merge branch 'dev' into fix/3206-update-thumbnail-component
finnar-bin Mar 24, 2025
a9913db
Merge branch 'dev' into fix/3206-update-thumbnail-component
finnar-bin Mar 26, 2025
2d0f36d
Merge branch 'dev' into fix/3206-update-thumbnail-component
finnar-bin Mar 27, 2025
8dc3773
Merge branch 'dev' into fix/3206-update-thumbnail-component
finnar-bin Apr 1, 2025
3586db7
Merge branch 'dev' into fix/3206-update-thumbnail-component
finnar-bin Apr 4, 2025
c8c0b37
Merge branch 'dev' into fix/3206-update-thumbnail-component
finnar-bin Apr 7, 2025
98f0ad2
Merge branch 'dev' into fix/3206-update-thumbnail-component
finnar-bin Apr 21, 2025
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
@@ -1,16 +1,58 @@
import { GridRenderCellParams } from "@mui/x-data-grid-pro";
import { Box, Stack } from "@mui/material";
import { Box, Skeleton, Stack } from "@mui/material";
import { ImageRounded } from "@mui/icons-material";
import { useState } from "react";
import { useSelector } from "react-redux";

import { FileTypePreview } from "../../../../../../media/src/app/components/FileModal/FileTypePreview";
import {
useGetAllBinFilesQuery,
useGetBinsQuery,
useLazyGetFileQuery,
} from "../../../../../../../shell/services/mediaManager";
import { AppState } from "../../../../../../../shell/store/types";
import { useEffect, useMemo, useState } from "react";
import { File } from "../../../../../../../shell/services/types";

type ImageCellProps = { params: GridRenderCellParams };
export const ImageCell = ({ params }: ImageCellProps) => {
const [hasError, setHasError] = useState(false);
const handleImageError = () => {
setHasError(true);
};
const [fileData, setFileData] = useState<File>(null);
const instance = useSelector((state: AppState) => state.instance);
const isFileZUID = !!params.value?.startsWith("3-");

const { data: bins, isFetching: isFetchingBins } = useGetBinsQuery({
instanceId: instance?.ID,
ecoId: instance?.ecoID,
});
const [getFile] = useLazyGetFileQuery();

// Query below will not necessarily be made on every render as this
// is already performed on component load, we're simply accessing the cached data
const { data: allMediaFiles, isFetching: isFetchingAllMediaFiles } =
useGetAllBinFilesQuery(
bins?.map((bin) => bin.id),
{ skip: !bins?.length }
);
useEffect(() => {
if (isFetchingAllMediaFiles || !isFileZUID) return;

const matchedFile = allMediaFiles?.find((file) => file.id === params.value);

if (!params.value || hasError) {
if (!matchedFile) {
// If cache doesn't have the file data, attempt to look it up from the server
Copy link
Contributor

@agalin920 agalin920 Mar 18, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

@agalin920 agalin920 Mar 19, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor Author

@finnar-bin finnar-bin Mar 20, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

@finnar-bin finnar-bin Mar 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

getFile(params.value)
.unwrap()
.then((res) => {
setFileData(res);
})
.catch((err: any) => {
console.error(err);
});
} else {
setFileData(matchedFile);
}
}, [allMediaFiles, params.value, isFetchingAllMediaFiles]);

if (!params.value) {
return (
<Stack
sx={{
Expand All @@ -28,18 +70,55 @@ export const ImageCell = ({ params }: ImageCellProps) => {
);
}

if (isFileZUID) {
if (isFetchingAllMediaFiles || isFetchingBins) {
return (
<Skeleton
variant="rectangular"
width="100%"
height="100%"
animation="wave"
/>
);
}

return (
<Box
sx={{
height: "100%",
width: "100%",

"[data-cy='file-preview']": {
width: "100%",
},
}}
>
<FileTypePreview
isMediaThumbnail
src={fileData?.url}
filename={fileData?.filename}
updatedAt={fileData?.updated_at}
/>
</Box>
);
}

return (
<Box
component="img"
sx={{
backgroundColor: (theme) => theme.palette.grey[100],
objectFit: "contain",
zIndex: -1,
height: "100%",
width: "100%",

"[data-cy='file-preview']": {
width: "100%",
},
}}
width="68px"
height="58px"
src={params.value}
onError={handleImageError}
/>
>
<FileTypePreview
isMediaThumbnail
src={params?.value}
filename={params?.value?.split("/").pop()}
/>
</Box>
);
};
10 changes: 2 additions & 8 deletions src/apps/content-editor/src/app/views/ItemList/index.tsx
Original file line number Diff line number Diff line change
Expand Up @@ -237,15 +237,9 @@ export const ItemList = () => {
const value = data[key] as string;

switch (fieldType) {
case "images": {
const parts = value?.split(",") || [];
const firstPart = parts[0];
clonedItem.data[key] = firstPart?.startsWith("3-")
? // @ts-ignore
`${CONFIG.SERVICE_MEDIA_RESOLVER}/resolve/${firstPart}/getimage/?w=68&h=auto&type=fit`
: firstPart;
case "images":
clonedItem.data[key] = value?.split(",")?.[0];
break;
}
case "internal_link":
case "one_to_one":
clonedItem.data[key] = resolveFieldRelationshipTitle(
Expand Down
2 changes: 1 addition & 1 deletion src/shell/components/Favicon/index.tsx
Original file line number Diff line number Diff line change
Expand Up @@ -76,7 +76,7 @@ export const Favicon = ({ onCloseFaviconModal }: FaviconProps) => {
] = useCreateHeadTagMutation();
const { data: bins, isFetching: isFetchingBins } = useGetBinsQuery({
instanceId: instance?.ID,
ecoId: instance?.ecoId,
ecoId: instance?.ecoID,
});
const { data: allMediaFiles, isFetching: isFetchingAllMediaFiles } =
useGetAllBinFilesQuery(
Expand Down
Loading