The current behaviour will intersect if the page is scrolled about 90% down
which works okay for a small number of assets, but does not scale well with
large amounts of assets. Instead of relying in proportional values, it may be
more sensible to use a consistent measure for loading more pages. A simple and
sensible suggestion may be to load another page when there is only one more
viewport worth of assets to display. It can be refined and revisited in future,
but it seems to work relatively well in my testing and prevents the issues
which occur with large amounts of assets.
Co-authored-by: Alex <alex.tran1502@gmail.com>
* Migrate from npm to pnpm across entire project
• Update all GitHub workflow files to use pnpm instead of npm
• Replace npm commands with pnpm equivalents in devcontainer scripts
• Remove package-lock.json files and update to use pnpm-lock.yaml
• Consolidate node version references to use server/.nvmrc
* Refine pnpm migration based on review feedback
• Replace SKIP_SHARP_FILTERING with SHARP_IGNORE_GLOBAL_LIBVIPS environment variable
• Improve Sharp package filtering to include specific Linux architectures for Docker builds
• Optimize Dockerfile dependency caching with improved layer structure
• Clean up workspace configuration and remove redundant settings
* Address additional review feedback for pnpm migration
• Fix node-version-file paths in GitHub workflow configurations
• Refactor .pnpmfile.cjs to use switch statement for better code organization
• Correct cache type typo in fix-format workflow
• Simplify Vite configuration by merging configs inline
• Update package description for consistency
* Use 'server/.nvmrc' for fix-format.yml GHA
* Delete npm locks
* Remove Docker volume isolation for node_modules directories
• Remove volume mounts for node_modules and related directories
• Allow shared access between host and container filesystem
• Update init container to handle file ownership with conditional existence check
* Remove unused Docker volumes and volume mounts
• Remove node_modules volume mounts from devcontainer configuration
• Remove unused named volumes for pnpm-store, node_modules, and cache directories
• Clean up Docker Compose configuration after removing volume isolation
* Fix typescript-sdk package issues
• Remove unknown "build" dependency that was incorrectly added to package.json
• Update pnpm-lock.yaml to reflect dependency removal
* Add pnpm setup to mobile workflow for translation formatting
• Add pnpm action setup step to mobile unit tests workflow
• Required for translation file formatting and sorting operations
---------
Co-authored-by: Jason Rasmussen <jason@rasm.me>
The height of the search results element was unrestricted, which meant that the
asset visibility calculations were completely incorrect. The consequence of
this is that assets which should not have been visible, were. In practical
terms, all assets below the viewport were rendered when they shouldn't have
been which is terrible for performance. Limiting the height of the viewport
fixes that calculation and assets are correctly hidden.
The consequence of limiting the height of the viewport is that the intersector
then incorrectly thought the scroll position was always at the end. This has
been fixed by calculating the position of sliding window against the calculated
asset layout container height.
Co-authored-by: Alex <alex.tran1502@gmail.com>
The thumbhash had a z-index setting which meant it would cover the search bar,
and would always cause weird animations when scrolling up in search results.
This is fixable by removing the z-index and moving it in front the other
elements to get a naturally higher higher z-index preference.
The contents of search results are slightly offset by the search bar, search
terms and spacing (margins/padding), and needs to be factored in when
calculating whether an asset is visible or not. The offset was 0, which
meant that assets were removed from view too early.
The timeline has been quite aggressive with scrolling to assets, even if they
were right in the middle of the page. If the asset is visible, then we
shouldn't scroll to it. It's really confusing when assets jump around after
being viewed.
The search results page can become unstable with large amounts of assets, and
has therefore been limited to displaying just 5000 assets. This limit is
arbitrary and may be too restrictive.
Fix the calculation for the date group width, so there's never a scenario where photos will be hidden. On mobile devices, photos in the second row can sometimes have a top of <100px, which throws off the calculation of the date group width.
