fix(MyCollection): 다이어리 리스트 로딩기능 추가

[mark77234]

변경점 👍

새로 구현한 기능 및 주요 변경점

버그 해결 💊

해결한 버그

테스트 💻

변경점을 테스트하기 위한 방법 기술

스크린샷 🖼

변경된 부분에 대한 스크린샷

비고 ✏

리뷰어에게 전하는 말 등

사용하지 않은 항목은 모두 지워주세요.

[Copilot]

Pull request overview

This PR adds pagination/infinite scroll functionality to the MyCollection view, allowing users to load additional diary feeds as they scroll down the list.

Changes:

• Implemented pagination logic in MyCollectionViewModel with proper state management for loading more feeds
• Added loading indicator UI for pagination in MyCollectionView
• Enhanced DiaryService with static default constants and input validation for page parameters

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 7 comments.

File	Description
KillingPart/Services/DiaryService.swift	Added static constants for default page/size and parameter validation to prevent invalid requests
KillingPart/ViewModels/My/MyCollection/MyCollectionViewModel.swift	Implemented pagination state management, added loadMoreMyFeedsIfNeeded method, and refactored loadMyFeeds to support both initial and pagination modes
KillingPart/Views/Screens/Main/My/MyCollection/MyCollectionView.swift	Added onAppear trigger for pagination on feed cards and loading indicator UI for pagination state

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

When pagination mode encounters an error, it overwrites the errorMessage. This means if the initial load succeeds but pagination fails, the error message will be displayed even though the user can still see the initial content. Consider either: (1) not overwriting errorMessage in pagination mode, (2) having a separate error state for pagination errors, or (3) showing a toast/temporary notification for pagination errors instead of persisting in errorMessage.

Suggested change

	errorMessage = resolveErrorMessage(from: error)
	if mode == .initial {
	errorMessage = resolveErrorMessage(from: error)
	}

[Copilot]

The deduplication logic filters out feeds that already exist by ID. However, if the API returns the same feed multiple times across different pages (which could happen with concurrent modifications or race conditions in the backend), this will silently skip those feeds. While this prevents duplicates, it could also lead to confusion if users expect to see a certain number of items per page. Consider logging when duplicates are encountered to help diagnose potential backend issues.

Suggested change

	let newFeeds = response.content.filter { !existingFeedIDs.contains($0.id) }
	let newFeeds = response.content.filter { !existingFeedIDs.contains($0.id) }
	let duplicateCount = response.content.count - newFeeds.count
	if duplicateCount > 0 {
	print("MyCollectionViewModel.loadMyFeeds: Skipped \(duplicateCount) duplicate feed(s) for page \(page).")
	}

[Copilot]

The resolvedPage validation uses max(page, Self.defaultPage), which means negative page numbers are clamped to 0. However, this silently corrects invalid input rather than failing fast. If negative page numbers are being passed, it indicates a logic error in the caller that should be addressed. Consider either: (1) asserting that page >= 0 in debug builds, or (2) documenting that negative values are automatically corrected to 0.

Suggested change

	) async throws -> MyDiaryFeedsResponse {
	) async throws -> MyDiaryFeedsResponse {
	assert(page >= 0, "DiaryService.fetchMyFeeds(page:size:): page must be >= 0")

[Copilot]

The nextFeedPage is initialized to 0 and hasNextFeedPage is initialized to true, which means these variables have incorrect values before the first load completes. If a user somehow triggers loadMoreMyFeedsIfNeeded before the initial load finishes (though currently prevented by the hasLoadedMyFeeds guard), it would try to load page 0 again. Consider initializing nextFeedPage to 1 or making hasNextFeedPage start as false to better represent the initial state before any data is loaded.

Suggested change

	private var hasNextFeedPage = true
	private var hasNextFeedPage = false

[Copilot]

When the initial load returns an empty result (0 feeds), hasLoadedMyFeeds is set to true and nextFeedPage/hasNextFeedPage are calculated based on the response. However, with no feeds in the list, loadMoreMyFeedsIfNeeded can never be triggered (since it requires a feed to appear). If the server later has new content, the user would need to manually refresh to see it. Consider adding a pull-to-refresh mechanism to allow users to reload the list, or reset hasLoadedMyFeeds to false when the result is empty so subsequent app activations can retry.

[Copilot]

When pagination fails, the pagination state variables (nextFeedPage, hasNextFeedPage) are not updated, but hasLoadedMyFeeds remains true. This means that if the first page loads successfully but the second page fails, the pagination will be broken - subsequent attempts to load more will continue requesting the failed page number. Consider updating pagination state in the error case, or resetting hasNextFeedPage when an error occurs during pagination mode.

Suggested change

	errorMessage = resolveErrorMessage(from: error)
	errorMessage = resolveErrorMessage(from: error)
	if mode == .pagination {
	hasNextFeedPage = false
	}

[Copilot]

In a LazyVGrid with 2 columns, when scrolling near the end of the list, both items in the last row will trigger onAppear simultaneously, causing loadMoreMyFeedsIfNeeded to be called twice in quick succession. While the isLoadingMyFeeds guard should prevent the second call from executing, this is still inefficient. Consider adding a threshold offset (e.g., only trigger when within the last 3-5 items instead of the very last item) to reduce redundant calls.