In the "vertical mode" intersection changes for the left or right side of the element do not matter.
Same for "horizontal mode" the other way around.
If not handled accordingly, it would cause unwanted chapter changes.
The viewers can have different sizes which caused theme to not be properly centered.
E.g. for the "vertical mode" in case "chapter 1" is greater in width than "chapter 2", the pages of "chapter 2" were not correctly centered due to the "viewers" having different widths.
Seems like not all browsers handle
width/height: 100%
min-width/min-height: fit-content
correctly.
the "min" setting just never applies and the size is stuck at 100%.
In case many chapters are rendered, even just the HOC wrapper component re-render due to the context change increases the render time.
Thus, getting rid of these HOC wrapper re-renders by moving the context usage up to the ReaderViewer decreases the render time.
In case many chapters are rendered, even just the HOC wrapper component re-render due to the context change increases the render time.
Thus, getting rid of these HOC wrapper re-renders by moving the context usage up to the ReaderViewer decreases the render time.
Preparation for infinite scroll, since there will be a wrapper which fits its content in width and height, thus, percentage based dimension won't work anymore
In case the current chapter should get deleted after reading it, it only worked in case it was already marked as read due to checking the read status from the chapter itself instead of the chapter update patch input
ReaderControls#useUpdateCurrentPageIndex:
On a page change the chapter update needs to be always queued since the deletion of downloaded chapters while reading logic is in the "ReaderService#updateChapter" function.
Thus, when the update is prevented here, this logic would never get triggered.
ReaderService#useUpdateChapter:
In case the read status or lastPageRead of a chapter did not change, the update was not triggered.
However, there might still be chapter downloads that need to be de deleted, which was never handled in such a case.
Instead of getting the whole download status, which contains all queued/active downloads, the download status should be read from the cache for only the required chapters
Chapter numbers can change from e.g. "1" to "2.1" and in that case missing chapters were detected.
However, with these weird chapter numbers it's not clear if a chapter is actually missing or not, thus, they should not cause a missing chapter warning
Automatically choose the progress bar position based on the available space.
Previously it was only possible to automatically switch from a horizontal to a vertical position but not the other way around
By the time the scroll area got scrolled to the start of the visible pages, the previous/next page wasn't yet shown and thus, the scrollable area wasn't updated yet.
Thus, in case the scrollable area grew in width due to the page change, the start never got scrolled into view due to triggering the logic too early.
The wrong chapter list was used.
"chapters" is the filtered list of chapters, which e.g. doesn't contain duplicated chapters.
This caused the "chapter source order" to potentially be higher than the total chapters of the manga.
The end result of this was that the fetched state of the pages wasn't properly detected causing errors due to rendering the reader before it was in the correct state
