{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":626673625,"defaultBranch":"master","name":"Justified-Gallery","ownerLogin":"cgunther","currentUserCanPush":false,"isFork":true,"isEmpty":false,"createdAt":"2023-04-12T00:09:11.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/107416?v=4","public":true,"private":false,"isOrgOwned":false},"refInfo":{"name":"","listCacheKey":"v0:1717078487.0","currentOid":""},"activityList":{"items":[{"before":"50c46a12869fb00cfe00cba44757941377f013e2","after":"60abdd05628fa6326fa1956ba5d0b3481e425452","ref":"refs/heads/fix-offset-and-sizing-yarn-v4","pushedAt":"2024-05-30T14:25:25.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"cgunther","name":"Chris Gunther","path":"/cgunther","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/107416?s=80&v=4"},"commit":{"message":"Upgrade to Yarn v4 for local development\n\nHit an issue on SiteSwan in CI where it tried to install Yarn classic to\npack the dependency since we point to a fork/branch, but then the\nchecksum of the packed archive didn't match what the lockfile called\nfor.\n\nThis seemed to pop up out of nowhere. I noticed we used to install Yarn\nv1.22.19 for this step, but now it's installing Yarn v1.22.22, so maybe\nthat's a culprit?\n\nUltimately switching our lockfile to the newer Yarn avoids SiteSwan CI\ninstalling Classic Yarn for packing, which seems to resolve our issue.","shortMessageHtmlLink":"Upgrade to Yarn v4 for local development"}},{"before":null,"after":"50c46a12869fb00cfe00cba44757941377f013e2","ref":"refs/heads/fix-offset-and-sizing-yarn-v4","pushedAt":"2024-05-30T14:14:47.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"cgunther","name":"Chris Gunther","path":"/cgunther","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/107416?s=80&v=4"},"commit":{"message":"Upgrade to Yarn v4 for local development","shortMessageHtmlLink":"Upgrade to Yarn v4 for local development"}},{"before":"877d326626c7a0b9b535ee9bd85eb71a509ecee0","after":"3039deeca04c4780faa3930bb6aaf3af82abbbc3","ref":"refs/heads/fix-offset-and-sizing","pushedAt":"2023-04-12T00:12:17.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"cgunther","name":"Chris Gunther","path":"/cgunther","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/107416?s=80&v=4"},"commit":{"message":"Properly fix wrong offset calculation\n\nPR #286 attempted to fix a doubled margin between rows, however in my\nuse case, while it solved that, it increased the images per row, thereby\nreducing the height of each image. Especially with a number of very\nwide, but short, images, this led each row to be significantly shorter\nthen before #286.\n\nI believe the source of that problem is that after #286, we'd buffer the\nnext entry, add it's aspect ratio in the `buildingRow`, then determine\nif the `buildingRow` (while accounting for the aspect ratio a second\ntime) was below the `rowHeight` to flush the row, thereby treating\n`rowHeight` like a maximum height.\n\nIt seems the intention prior to #286 was to tentatively add the next\nentry's aspect ratio, without buffering it in `buildingRow` yet, to\ndetermine if that'd push us below the `rowHeight`, and if so, flush the\nrow before that next entry, thereby treating the `rowHeight` like a\nminimum height.\n\nIn other words, before #286, we'd flush the row BEFORE adding the entry\nthat would push us below the configured `rowHeight`, but after #286,\nwe'd flush the row AFTER adding the entry that pushed us below the\n`rowHeight`.\n\nThe root source of the doubled margin was flushing a row with no\nbuffered entries (hence increasing the offset without actually rendering\na row). Given an empty buffered entries (start of a new row), if the\nentry being analyzed had an aspect ratio that'd make it's height less\nthan the configured `rowHeight`, we'd flush the row BEFORE buffering the\nentry, thereby flushing an empty row.\n\nNow, we only attempt to flush the row if we have at least one buffered\nentry.\n\nThis should still fix #223 and #275 without introducing the side-effects\ndescribed above.","shortMessageHtmlLink":"Properly fix wrong offset calculation"}},{"before":null,"after":"877d326626c7a0b9b535ee9bd85eb71a509ecee0","ref":"refs/heads/fix-offset-and-sizing","pushedAt":"2023-04-12T00:09:35.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"cgunther","name":"Chris Gunther","path":"/cgunther","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/107416?s=80&v=4"},"commit":{"message":"Properly fix wrong offset calculation\n\nPR #286 attempted to fix a doubled margin between rows, however in my\nuse case, while it solved that, it increased the images per row, thereby\nreducing the height of each image. Especially with a number of very\nwide, but short, images, this led each row to be significantly shorter\nthen before #286.\n\nI believe the source of that problem is that after #286, we'd buffer the\nnext entry, add it's aspect ratio in the `buildingRow`, then determine\nif the `buildingRow` (while accounting for the aspect ratio a second\ntime) was below the `rowHeight` to flush the row, thereby treating\n`rowHeight` like a maximum height.\n\nIt seems the intention prior to #286 was to tentatively add the next\nentry's aspect ratio, without buffering it in `buildingRow` yet, to\ndetermine if that's push us below the `rowHeight`, and if so, flush the\nrow before that next entry, thereby treating the `rowHeight` like a\nminimum height.\n\nIn other words, before #286, we'd flush the row BEFORE adding the entry\nthat would push us below the configured `rowHeight`, but after #286,\nwe'd flush the row AFTER adding the entry that pushed us below the\n`rowHeight`.\n\nThe root source of the doubled margin was flushing a row with no\nbuffered entries (hence increasing the offset without actually rendering\na row). Given an empty buffered entries (start of a new row), if the\nentry being analyzed had an aspect ratio that'd make it's height less\nthan the configured `rowHeight`, we'd flush the row BEFORE buffering the\nentry, thereby flushing an empty row.\n\nNow, we only attempt to flush the row if we have at least one buffered\nentry.\n\nThis should still fix #223 and #275 without introducing the side-effects\ndescribed above.","shortMessageHtmlLink":"Properly fix wrong offset calculation"}}],"hasNextPage":false,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"cursor":"djE6ks8AAAAEWBvQhQA","startCursor":null,"endCursor":null}},"title":"Activity · cgunther/Justified-Gallery"}