Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
[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
base: dev
Are you sure you want to change the base?
[Content] Improve image thumbnails #3224
Changes from all commits
9189516
264d15e
3d2cb3b
b57b71f
79ddf64
5bcb0c8
ffa91b8
67aa113
c48c421
6393ccd
2b29590
a9913db
2d0f36d
8dc3773
3586db7
c8c0b37
98f0ad2
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.There was a problem hiding this comment.
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.There was a problem hiding this comment.
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.There was a problem hiding this comment.
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?