-
Notifications
You must be signed in to change notification settings - Fork 0
[Fix] 소식 탭 오류 수정 및 유즈케이스 구현 및 적용 #155
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
Conversation
- 이미지 URL은 옵셔널 타입
WalkthroughThe pull request removes the Changes
Sequence Diagram(s)sequenceDiagram
participant VC as ViewController
participant VM as ViewModel
participant UC as OverviewUseCase
VC->>VM: Trigger view load/refresh event
VM->>UC: Call data fetch methods (e.g., fetchGameCategory, fetchNews)
UC-->>VM: Return data (or error) via publisher
VM->>VC: Update UI with fetched data
Assessment against linked issues
Suggested reviewers
✨ Finishing Touches
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
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.
Actionable comments posted: 0
🧹 Nitpick comments (9)
Wable-iOS/Presentation/Overview/Rank/View/RankListViewController.swift (1)
44-56: Good implementation of highlighted text in button titleThe implementation cleverly uses
NSMutableAttributedStringto highlight the "의견 남기러 가기" portion of the button text with a sky blue color, which likely improves UI clarity and visual hierarchy.One potential improvement to consider would be extracting this text styling logic into a reusable helper method if this pattern is used elsewhere in the codebase.
private let submitButton = WableButton(style: .black).then { var config = $0.configuration - let fullText = NSMutableAttributedString(Constant.submitButtonTitle.pretendardString(with: .body3)) - if let range = Constant.submitButtonTitle.range(of: "의견 남기러 가기") { - fullText.addAttributes( - [.foregroundColor: UIColor.sky50], - range: NSRange(range, in: Constant.submitButtonTitle) - ) - } - - config?.attributedTitle = AttributedString(fullText) + config?.attributedTitle = AttributedString(createHighlightedText( + fullText: Constant.submitButtonTitle, + highlightedPart: "의견 남기러 가기", + highlightColor: .sky50 + )) $0.configuration = config } // Add this helper method to the extension private func createHighlightedText(fullText: String, highlightedPart: String, highlightColor: UIColor) -> NSAttributedString { let attributedString = NSMutableAttributedString(fullText.pretendardString(with: .body3)) if let range = fullText.range(of: highlightedPart) { attributedString.addAttributes( [.foregroundColor: highlightColor], range: NSRange(range, in: fullText) ) } return attributedString }Wable-iOS/Presentation/Overview/Page/View/OverviewPageViewController.swift (2)
141-144: Remove TODO comment in production code.The TODO comment indicates that it should be removed in the future. Consider removing it now or add more context about when it should be removed.
- // TODO: 추후 주석 삭제 요망 - let useCase = MockOverviewUseCaseImpl() // let useCase = OverviewUseCaseImpl()🧰 Tools
🪛 SwiftLint (0.57.0)
[Warning] 141-141: TODOs should be resolved (추후 주석 삭제 요망)
(todo)
143-144: Consider implementing factory pattern for switching between mock and real implementations.Currently, you're using the mock implementation with a commented out real implementation. As mentioned in your PR description, a factory pattern would be beneficial here to easily switch between mock and real implementations.
- let useCase = MockOverviewUseCaseImpl() -// let useCase = OverviewUseCaseImpl() + let useCase: OverviewUseCase = AppEnvironment.isTestMode ? + MockOverviewUseCaseImpl() : + OverviewUseCaseImpl()Wable-iOS/Presentation/Overview/GameSchedule/ViewModel/GameScheduleViewModel.swift (1)
33-38: Consider enhanced error handling for the replaced calls.
UsingreplaceError(with: "")orreplaceError(with: [])helps avoid crashes, but it also swallows the error. If applicable, consider adding user-visible error handling or logging to provide better feedback.Wable-iOS/Presentation/Overview/News/ViewModel/NewsViewModel.swift (1)
40-51: Refresh pipeline logic is coherent.
MergingviewDidLoadandviewDidRefresh, setting loading states, and then fetching the news from theuseCaseis a clean approach. Consider verifying whether ignoring fetch errors completely is acceptable or if a fallback UI state is required.Wable-iOS/Domain/UseCase/Overview/OverviewUseCase.swift (4)
13-20: Recommend brief documentation for protocol methods.
Adding concise docstrings for each method inOverviewUseCasecan clarify their behavior, parameters, and error contracts for future maintainers.
49-49: Address TODO comment.
The TODO indicates a pending comparison between server data and local storage. Consider resolving this soon to ensure thecheckNewAnnouncements()method accurately reflects production requirements.Would you like me to propose a possible approach for storing and comparing local data?
🧰 Tools
🪛 SwiftLint (0.57.0)
[Warning] 49-49: TODOs should be resolved (서버에서 받아오는 값과 로컬에 저장한 값을 비교 후, ...)
(todo)
66-70: Mock: Consider making "2025 LCK SPRING" configurable.
Hardcoding the season's name is fine for temporary usage, but introducing a parameter or config can make tests more flexible in the future.
102-129: Review the .just([]) return increateMockGameSchedules().
It looks like actual mock data is generated but ultimately not returned. Returning an empty array might limit the realism of your mock. If this is intentional, please disregard. Otherwise, consider returningmockGameSchedulesfor more accurate test scenarios.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (20)
Wable-iOS.xcodeproj/project.pbxproj(0 hunks)Wable-iOS/App/AppDelegate+InjectDependency.swift(1 hunks)Wable-iOS/Data/Mapper/InformationMapper.swift(2 hunks)Wable-iOS/Data/RepositoryImpl/InformationRepositoryImpl.swift(0 hunks)Wable-iOS/Domain/UseCase/Overview/OverviewUseCase.swift(1 hunks)Wable-iOS/Infra/Network/DTO/Response/Information/FetchNews.swift(1 hunks)Wable-iOS/Infra/Network/DTO/Response/Information/FetchNotices.swift(1 hunks)Wable-iOS/Presentation/Overview/Detail/View/AnnouncementDetailViewController.swift(2 hunks)Wable-iOS/Presentation/Overview/Detail/View/Subview/AnnouncementDetailView.swift(2 hunks)Wable-iOS/Presentation/Overview/GameSchedule/View/GameScheduleListViewController.swift(4 hunks)Wable-iOS/Presentation/Overview/GameSchedule/View/Subview/GameScheduleEmptyView.swift(0 hunks)Wable-iOS/Presentation/Overview/GameSchedule/ViewModel/GameScheduleViewModel.swift(2 hunks)Wable-iOS/Presentation/Overview/News/View/NewsViewController.swift(1 hunks)Wable-iOS/Presentation/Overview/News/ViewModel/NewsViewModel.swift(4 hunks)Wable-iOS/Presentation/Overview/Notice/View/Cell/NoticeCell.swift(1 hunks)Wable-iOS/Presentation/Overview/Notice/View/NoticeViewController.swift(1 hunks)Wable-iOS/Presentation/Overview/Notice/ViewModel/NoticeViewModel.swift(4 hunks)Wable-iOS/Presentation/Overview/Page/View/OverviewPageViewController.swift(1 hunks)Wable-iOS/Presentation/Overview/Rank/View/RankListViewController.swift(2 hunks)Wable-iOS/Presentation/Overview/Rank/ViewModel/RankViewModel.swift(2 hunks)
💤 Files with no reviewable changes (3)
- Wable-iOS/Presentation/Overview/GameSchedule/View/Subview/GameScheduleEmptyView.swift
- Wable-iOS/Data/RepositoryImpl/InformationRepositoryImpl.swift
- Wable-iOS.xcodeproj/project.pbxproj
🧰 Additional context used
🧬 Code Definitions (5)
Wable-iOS/Presentation/Overview/GameSchedule/ViewModel/GameScheduleViewModel.swift (1)
Wable-iOS/Domain/UseCase/Overview/OverviewUseCase.swift (4)
fetchGameCategory(27-29)fetchGameCategory(66-70)fetchGameSchedules(31-33)fetchGameSchedules(72-76)
Wable-iOS/Presentation/Overview/Rank/ViewModel/RankViewModel.swift (1)
Wable-iOS/Domain/UseCase/Overview/OverviewUseCase.swift (4)
fetchGameCategory(27-29)fetchGameCategory(66-70)fetchTeamRanks(35-37)fetchTeamRanks(78-82)
Wable-iOS/Presentation/Overview/News/ViewModel/NewsViewModel.swift (3)
Wable-iOS/Data/RepositoryImpl/InformationRepositoryImpl.swift (1)
fetchNews(54-61)Wable-iOS/Domain/UseCase/Overview/OverviewUseCase.swift (2)
fetchNews(39-41)fetchNews(84-88)Wable-iOS/Presentation/Overview/Notice/ViewModel/NoticeViewModel.swift (1)
isLastPage(107-109)
Wable-iOS/Presentation/Overview/Notice/ViewModel/NoticeViewModel.swift (2)
Wable-iOS/Domain/UseCase/Overview/OverviewUseCase.swift (2)
fetchNotices(43-45)fetchNotices(90-94)Wable-iOS/Presentation/Overview/News/ViewModel/NewsViewModel.swift (1)
isLastPage(109-111)
Wable-iOS/Domain/UseCase/Overview/OverviewUseCase.swift (3)
Wable-iOS/Data/RepositoryImpl/InformationRepositoryImpl.swift (5)
fetchGameCategory(27-34)fetchGameSchedules(18-25)fetchTeamRanks(36-43)fetchNews(54-61)fetchNotice(63-70)Wable-iOS/Presentation/Overview/News/ViewModel/NewsViewModel.swift (1)
fetchNews(100-107)Wable-iOS/Presentation/Overview/Notice/ViewModel/NoticeViewModel.swift (1)
fetchNotices(98-105)
🪛 SwiftLint (0.57.0)
Wable-iOS/Presentation/Overview/Page/View/OverviewPageViewController.swift
[Warning] 141-141: TODOs should be resolved (추후 주석 삭제 요망)
(todo)
Wable-iOS/Domain/UseCase/Overview/OverviewUseCase.swift
[Warning] 49-49: TODOs should be resolved (서버에서 받아오는 값과 로컬에 저장한 값을 비교 후, ...)
(todo)
🔇 Additional comments (39)
Wable-iOS/Presentation/Overview/Detail/View/Subview/AnnouncementDetailView.swift (2)
162-162: Good improvement to respect safe area boundaries.Anchoring the bottom of the contentStackView to the safe area instead of the superview will prevent content from extending into system UI elements like the home indicator on newer iPhones. This is an important fix for devices with notches or home bars.
175-175: Better alignment for timeLabel.Aligning the timeLabel with the top of the titleLabel instead of centering it vertically provides more consistent visual positioning, especially when the title spans multiple lines. This improves the layout when titles are long.
Wable-iOS/Presentation/Overview/Rank/View/RankListViewController.swift (2)
37-42: Clean initialization style for UICollectionViewThe change from using
.init()to directly using the constructorUICollectionView()is a good stylistic improvement that enhances code readability.
63-63: Clean initialization style for CancelBagUsing
CancelBag()rather than.init()is a cleaner and more standard way to initialize objects in Swift. This improved consistency with Swift idioms.Wable-iOS/Infra/Network/DTO/Response/Information/FetchNotices.swift (1)
18-18: Good modification to handle optional image URLs.Changing
noticeImageURLto an optional type (String?) makes the DTO more resilient when handling API responses where the image URL might not be present. This change aligns with best practices for working with potentially nullable API fields.Since this is a data model change, ensure that any code using this property is updated to handle the optional value correctly, particularly when mapping to domain models.
Wable-iOS/Infra/Network/DTO/Response/Information/FetchNews.swift (1)
18-18: Appropriate change for handling optional news image URLs.Making
newsImageURLoptional (String?) is a good approach for handling cases where the API response might not include an image URL. This change is consistent with the similar modification made to theFetchNoticesstruct.Make sure any related mappers or presenters properly handle this nullable value to avoid unexpected UI behavior.
Wable-iOS/Presentation/Overview/Notice/View/NoticeViewController.swift (1)
238-238: Improved collection view layout with estimated height.Changing from
.fractionalHeight(1)to.estimated(96.adjustedHeight)is a good improvement for the collection view layout. This approach:
- Allows for more accurate height calculations based on content
- Improves scrolling performance by providing the system with a realistic height estimate
- Better handles variable-height content than a fixed fractional height
This change aligns well with standard UICollectionView best practices for dynamic content.
Wable-iOS/Presentation/Overview/Notice/View/Cell/NoticeCell.swift (1)
90-90: Consider the implications of using a fixed bottom constraint.Changing from
make.bottom.lessThanOrEqualToSuperview().offset(-12)tomake.bottom.equalToSuperview().offset(-12)makes the constraint more rigid.The previous constraint allowed the label's bottom edge to adjust when content was shorter than expected, while ensuring it never got closer than 12 points to the bottom. The new fixed constraint might:
- Force a minimum cell height even with minimal content
- Potentially cut off text if the content exceeds available space, since
numberOfLinesis set to 2Consider if this is the intended behavior or if the more flexible constraint was better for variable content.
Wable-iOS/App/AppDelegate+InjectDependency.swift (1)
14-14: Good implementation of dependency injection.This change properly registers the
InformationRepositoryImplfor theInformationRepositoryinterface in the dependency injection container, which aligns with the PR objective of registering repository dependencies. This enables easier access to the repository through the@Injectedproperty wrapper as mentioned in the PR description.Wable-iOS/Presentation/Overview/News/View/NewsViewController.swift (2)
35-41: LGTM: Simplified collection view initialization.The change from using
.init()syntax to directly calling the constructor is a good stylistic improvement that makes the code cleaner.
43-46: Note about missing emptyLabel.isHidden setting.The previous code may have set
emptyLabel.isHidden = trueinitially, which has been removed. This is fine as long as the visibility is properly managed in thesetupBinding()method (which it appears to be at line 199).Wable-iOS/Data/Mapper/InformationMapper.swift (2)
60-60: Good fix for handling optional image URLs.This change properly handles cases where the newsImageURL might be nil by using the nil-coalescing operator, preventing potential issues when creating URL objects.
76-76: Good fix for handling optional image URLs.Similar to the news image URL handling, this change properly handles cases where the noticeImageURL might be nil, preventing potential issues when creating URL objects.
Wable-iOS/Presentation/Overview/Page/View/OverviewPageViewController.swift (2)
146-151: Good refactoring to use the UseCase pattern.The transition from using repository directly to using a UseCase is a good architectural improvement that better separates concerns.
153-160: Improved code organization.Using an array followed by a forEach loop is a cleaner approach than multiple append calls.
Wable-iOS/Presentation/Overview/GameSchedule/View/GameScheduleListViewController.swift (4)
44-46: Clean replacement of GameScheduleEmptyView with UIImageViewThe switch from a custom empty view to a standard UIImageView simplifies the code while maintaining the same functionality. Setting the content mode to
.scaleAspectFitensures the image will be displayed properly.
95-96: Appropriate view hierarchy updateThe view hierarchy has been properly updated to include the new emptyImageView in place of the previous emptyView.
104-108: Constraints look goodThe constraints correctly center the empty image and set appropriate dimensions with the adjusted sizing helpers to handle different device sizes.
225-225: Visibility logic is correctly implementedThe condition for showing/hiding the empty state has been properly updated to use the new emptyImageView. The logic is correct - show the empty image when there are no items.
Wable-iOS/Presentation/Overview/Detail/View/AnnouncementDetailViewController.swift (3)
37-41: Good UX improvement by hiding tab barSetting
hidesBottomBarWhenPushed = truein the initializer ensures a cleaner UI when navigating to detail views, which is a good practice for detail screens.
43-46: Correctly preventing storyboard initializationMarking the required initializer as unavailable with a fatal error is the standard pattern to prevent unintended initialization from Interface Builder.
75-82: Improved image loading error handlingThe previous implementation likely didn't handle image loading failures. This update properly shows or hides the image view based on the loading result, providing better user experience when images fail to load.
Wable-iOS/Presentation/Overview/Notice/ViewModel/NoticeViewModel.swift (5)
12-16: Good architectural improvement using UseCase patternReplacing direct repository access with a UseCase abstraction follows clean architecture principles and improves separation of concerns. This change aligns with the PR objective of implementing and applying the UseCase pattern.
47-47: Repository access properly delegated to helper methodUsing the
fetchNoticeshelper method for both initial and pagination fetch operations provides consistent error handling and improves code organization.Also applies to: 67-67
49-52: Improved last page detection with helper methodExtracting the last page detection logic to a separate method makes the code more readable and consistent, especially since this logic is used in multiple places.
Also applies to: 69-72
97-105: Well-implemented error handlingThe helper method properly catches errors, logs them, and returns an empty array instead of propagating the error. This ensures the UI will still function even if the network request fails.
107-109: Clear and reusable pagination logicThe implementation of
isLastPageis clear and follows a standard pattern for determining the end of paginated data.Wable-iOS/Presentation/Overview/Rank/ViewModel/RankViewModel.swift (3)
12-16: Consistent application of UseCase patternThe changes in RankViewModel follow the same pattern applied to other view models, replacing repository direct access with UseCase abstraction. This consistency improves the overall architecture.
33-33: Appropriate delegation to UseCase methodsThe data fetching calls have been properly updated to use the UseCase methods instead of calling the repository directly, maintaining the same functionality with better architecture.
Also applies to: 38-38
42-43: Streamlined trigger logicThe view load and refresh triggers are now combined directly in the item publisher chain, which simplifies the code.
Wable-iOS/Presentation/Overview/GameSchedule/ViewModel/GameScheduleViewModel.swift (4)
12-12: UseCase property introduction looks good.
No issues found with declaringuseCasehere. The use ofprivatekeeps the property encapsulated.
14-15: Constructor refactor aligns with new architecture.
Replacing the repository parameter withuseCaseis consistent with the shift to a use case-driven approach.
45-45: Merging triggers is straightforward.
MergingviewDidLoadandviewDidRefreshinto a single publisher for subsequent mapping looks correct.
51-51: CombineLatest usage is correct.
CombiningfetchGameTypeandfetchGameSchedulesinto a single pipeline is a neat approach to retrieve the required data concurrently.Wable-iOS/Presentation/Overview/News/ViewModel/NewsViewModel.swift (4)
12-12: OverviewUseCase property introduction looks good.
Declaring a privateuseCaseproperty is consistent with the new architecture.
14-15: Constructor refactor approved.
Switching from repository touseCasein the initializer follows the same pattern found in other view models and is consistent with the domain-driven design.
69-73: Infinite scroll logic is well-handled.
Filtering out the isLastPage condition prevents redundant network calls. The approach forwillDisplayLastItemlooks good.
99-112: Helper extension provides clear separation of concerns.
Using a dedicatedfetchNews(with:)method that logs errors and returns an empty array is a pragmatic fallback. If you’d like to surface errors to the UI eventually, consider revisiting this approach. Also, theisLastPagelogic aligns with pagination best practices.Wable-iOS/Domain/UseCase/Overview/OverviewUseCase.swift (1)
148-173: Incremental approach to generating mock announcements is straightforward.
This chunk-based logic helps test pagination by simulating discrete pages of data. The fallback to.just([])for unexpected cursors is a sensible default.
youz2me
left a comment
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.
굿 !! 고생하셨습니다 작업 속도가 빠르시군요 ,,, 저도 분발하겠습니다.
| init() { | ||
| super.init(nibName: nil, bundle: nil) | ||
|
|
||
| hidesBottomBarWhenPushed = true |
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.
좋은 지식 알아갑니다 ,,,
| mockGameSchedules.append(GameSchedule(date: date, games: games)) | ||
| } | ||
|
|
||
| // return .just(mockGameSchedules) |
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.
필요없는 주석은 삭제 부탁드립니닷 !!
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.
네 반영했습니다!
# Conflicts: # Wable-iOS/Presentation/Overview/Rank/View/RankListViewController.swift # Wable-iOS/Presentation/Overview/Rank/ViewModel/RankViewModel.swift
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.
Actionable comments posted: 1
🧹 Nitpick comments (2)
Wable-iOS/Domain/UseCase/Overview/OverviewUseCase.swift (2)
47-55: Address the TODO incheckNewAnnouncements().
You have a placeholder returning(false, false). Completing this step is essential to ensure that the announcements are correctly checked against any locally stored reference.Would you like assistance implementing the comparison logic or opening a new issue to track this?
🧰 Tools
🪛 SwiftLint (0.57.0)
[Warning] 49-49: TODOs should be resolved (서버에서 받아오는 값과 로컬에 저장한 값을 비교 후, ...)
(todo)
60-63: Consider parameterizing the random delay in mocks.
UsingrandomDelaySecondis helpful to simulate asynchronous calls but may cause non-deterministic test outcomes. Consider adding a configurable parameter for test stability.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
Wable-iOS.xcodeproj/project.pbxproj(0 hunks)Wable-iOS/Domain/UseCase/Overview/OverviewUseCase.swift(1 hunks)Wable-iOS/Presentation/Overview/Rank/View/RankListViewController.swift(2 hunks)Wable-iOS/Presentation/Overview/Rank/ViewModel/RankViewModel.swift(2 hunks)
💤 Files with no reviewable changes (1)
- Wable-iOS.xcodeproj/project.pbxproj
🚧 Files skipped from review as they are similar to previous changes (2)
- Wable-iOS/Presentation/Overview/Rank/View/RankListViewController.swift
- Wable-iOS/Presentation/Overview/Rank/ViewModel/RankViewModel.swift
🧰 Additional context used
🧬 Code Definitions (1)
Wable-iOS/Domain/UseCase/Overview/OverviewUseCase.swift (1)
Wable-iOS/Data/RepositoryImpl/InformationRepositoryImpl.swift (5)
fetchGameCategory(27-34)fetchGameSchedules(18-25)fetchTeamRanks(36-43)fetchNews(54-61)fetchNotice(63-70)
🪛 SwiftLint (0.57.0)
Wable-iOS/Domain/UseCase/Overview/OverviewUseCase.swift
[Warning] 49-49: TODOs should be resolved (서버에서 받아오는 값과 로컬에 저장한 값을 비교 후, ...)
(todo)
🔇 Additional comments (2)
Wable-iOS/Domain/UseCase/Overview/OverviewUseCase.swift (2)
13-20: Great use of a dedicated protocol.
ThisOverviewUseCaseprotocol clearly defines the responsibilities and return types for fetching various data. The structure is easy to read and helps maintain a clean separation of concerns.
25-25:Details
✅ Verification successful
Verify DI container registration.
Ensure thatInformationRepositoryImplis properly registered for dependency injection so that@Injected private var repositoryresolves at runtime without errors.
🏁 Script executed:
#!/bin/bash # Description: Verify that `InformationRepositoryImpl` is registered in DIContainer rg -A 5 "InformationRepositoryImpl"Length of output: 5088
DI Container Registration Confirmed
The DI container registration forInformationRepositoryImplis properly set up. InWable-iOS/App/AppDelegate+InjectDependency.swift, the following registration is observed:diContainer.register(for: InformationRepository.self, object: InformationRepositoryImpl())No further modifications are required.
| private func createMockGameSchedules() -> AnyPublisher<[GameSchedule], WableError> { | ||
| var mockGameSchedules: [GameSchedule] = [] | ||
|
|
||
| for dayOffset in 0...6 { | ||
| let date = Calendar.current.date(byAdding: .day, value: dayOffset, to: Date())! | ||
| var games: [Game] = [] | ||
|
|
||
| for index in 0...4 { | ||
| let homeTeamIndex = index * 2 % lckTeams.count | ||
| let awayTeamIndex = (index * 2 + 1) % lckTeams.count | ||
|
|
||
| let game = Game( | ||
| date: date, | ||
| homeTeam: lckTeams[homeTeamIndex], | ||
| homeScore: index * 2 + 1, | ||
| awayTeam: lckTeams[awayTeamIndex], | ||
| awayScore: index * 2 + 2, | ||
| status: .scheduled | ||
| ) | ||
| games.append(game) | ||
| } | ||
|
|
||
| mockGameSchedules.append(GameSchedule(date: date, games: games)) | ||
| } | ||
|
|
||
| return .just([]) | ||
| } | ||
|
|
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.
Fix the return value to use the constructed schedules.
In createMockGameSchedules(), the function builds a non-empty mockGameSchedules array but returns .just([]) instead. This likely causes incorrect mock data in the UI or tests.
Apply this diff to fix the issue:
- return .just([])
+ return .just(mockGameSchedules)📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| private func createMockGameSchedules() -> AnyPublisher<[GameSchedule], WableError> { | |
| var mockGameSchedules: [GameSchedule] = [] | |
| for dayOffset in 0...6 { | |
| let date = Calendar.current.date(byAdding: .day, value: dayOffset, to: Date())! | |
| var games: [Game] = [] | |
| for index in 0...4 { | |
| let homeTeamIndex = index * 2 % lckTeams.count | |
| let awayTeamIndex = (index * 2 + 1) % lckTeams.count | |
| let game = Game( | |
| date: date, | |
| homeTeam: lckTeams[homeTeamIndex], | |
| homeScore: index * 2 + 1, | |
| awayTeam: lckTeams[awayTeamIndex], | |
| awayScore: index * 2 + 2, | |
| status: .scheduled | |
| ) | |
| games.append(game) | |
| } | |
| mockGameSchedules.append(GameSchedule(date: date, games: games)) | |
| } | |
| return .just([]) | |
| } | |
| private func createMockGameSchedules() -> AnyPublisher<[GameSchedule], WableError> { | |
| var mockGameSchedules: [GameSchedule] = [] | |
| for dayOffset in 0...6 { | |
| let date = Calendar.current.date(byAdding: .day, value: dayOffset, to: Date())! | |
| var games: [Game] = [] | |
| for index in 0...4 { | |
| let homeTeamIndex = index * 2 % lckTeams.count | |
| let awayTeamIndex = (index * 2 + 1) % lckTeams.count | |
| let game = Game( | |
| date: date, | |
| homeTeam: lckTeams[homeTeamIndex], | |
| homeScore: index * 2 + 1, | |
| awayTeam: lckTeams[awayTeamIndex], | |
| awayScore: index * 2 + 2, | |
| status: .scheduled | |
| ) | |
| games.append(game) | |
| } | |
| mockGameSchedules.append(GameSchedule(date: date, games: games)) | |
| } | |
| return .just(mockGameSchedules) | |
| } |
[Fix] 소식 탭 오류 수정 및 유즈케이스 구현 및 적용
👻 PULL REQUEST
📄 작업 내용
💻 주요 코드 설명
📍 버튼 타이틀 색 하이라이팅
특정 글자 색 하이라이팅
📍 레포지토리 의존성 등록 및 주입
@Injected를 통해 간편하게 주입될 수 있도록 하였습니다.레포지토리 의존성 등록 및 주입
👀 기타 더 이야기해볼 점
📍
pretendardString리턴 타입pretendardString메서드의 반환 타입을NSAttributedString에서NSMutableAttributedString으로 변경하는 것은 어떨까요?NSMutableAttributedString은NSAttributedString을 상속하므로 현재 코드에서 사용 중인 곳에서 호환성 문제 없이 대체할 수 있습니다.NSAttributedString은 생성 후 속성을 변경할 수 없는 반면,NSMutableAttributedString은 생성 후에도 속성을 동적으로 수정할 수 있어 더 유연하게 사용할 수 있습니다. 이렇게 변경하면 이 메서드를 사용하는 코드에서 필요한 경우 추가 속성을 설정하거나 기존 속성을 수정할 수 있게 됩니다.변경된
pretendardString을 사용할 경우NSAttributedString을NSMutableAttributedString으로 다시 변환하는 과정이 필요했지만, 메서드가 직접NSMutableAttributedString을 반환하므로 이 변환 단계가 필요 없어집니다.📍 Mock 객체와 실제 사용되는 객체 스위칭을 위한 팩토리 패턴 도입
🔗 연결된 이슈
Summary by CodeRabbit
New Features
Improvements
Refactors