Add expense

[cp-amisha-i]

Summary by CodeRabbit

• New Features
  • Introduced expense management capabilities, including adding, fetching, and deleting expenses.
  • Added new views and view models for adding expenses in the Splito app, enhancing the user interface and experience.
  • Improved group management by adding methods for group data retrieval and manipulation.
• Enhancements
  • Updated the fetchGroups method for better error handling and filtering logic.
  • Enhanced the expense and group stores with new functionalities and adjustments in error handling.
• Refactor
  • Removed unused MemberStore and MemberRepository declarations.
  • Adjusted function signatures and logic in GroupStore and ShareCodeStore to streamline operations.
• UI/UX Improvements
  • Implemented a new SwiftUI view for a user-friendly expense entry experience.
  • Added interactive elements to the home screen for managing expense sheets more intuitively.

[coderabbitai]

Warning

Rate Limit Exceeded

@cp-amisha-i has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 20 minutes and 7 seconds before requesting another review.

How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.
Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.
Please see our FAQ for further information.

Commits

Files that changed from the base of the PR and between 85f358c and 3628c49.

Walkthrough

The recent updates to the Splito app focus on enhancing the expense management features. New functionalities for adding, fetching, and deleting expenses have been introduced, alongside improvements in group management with error handling and data manipulation methods. The UI has been refined for a better user experience in adding expenses, and some architectural adjustments have been made, including the removal of certain member management components.

Changes

Files	Change Summary
Data.xcodeproj/project.pbxproj, Expense.swift, ExpenseRepository.swift, ExpenseStore.swift	New files for managing expenses added to the project.
.../Model/Expense.swift	Introduced Expense struct with properties and SplitType enum.
.../Repository/GroupRepository.swift, GroupStore.swift, ShareCodeStore.swift	Updated functions and logic for group and share code management.
.../Store/ExpenseStore.swift	Added class for managing expenses in Firestore.
.../Home/Expense/AddExpenseView.swift	New SwiftUI view for adding expenses.
.../UI/Home/HomeRouteView.swift	UI adjustments for expense sheet visibility and interaction enhancements.
.../DI/AppAssembly.swift	Removed registrations for MemberStore and MemberRepository.

🐰✨
In the land of code, where the rabbits hop,
A new update's here, with a skip and a bop.
Expenses tracked, and groups managed with care,
With a button press, add expenses to share.
So here's to the team, with a cheer and a clap,
For making Splito, a true treasure map.
🎉🥕

Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

Share

• X
• Mastodon
• Reddit
• LinkedIn

---

Tips

Chat

There are 3 ways to chat with CodeRabbit:

• Review comments: Directly reply to a review comment made by CodeRabbit. Example:
  • I pushed a fix in commit <commit_id>.
  • Generate unit-tests for this file.
  • Open a follow-up GitHub issue for this discussion.
• Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
  • @coderabbitai generate unit tests for this file.
  • @coderabbitai modularize this function.
• PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
  • @coderabbitai generate interesting stats about this repository and render them as a table.
  • @coderabbitai show all the console.log statements in this repository.
  • @coderabbitai read src/utils.ts and generate unit tests.
  • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.

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 as PR comments)

• @coderabbitai pause to pause the reviews on a PR.
• @coderabbitai resume to resume the paused reviews.
• @coderabbitai review to trigger a review. This is useful when automatic reviews are disabled for the repository.
• @coderabbitai resolve resolve all the CodeRabbit review comments.
• @coderabbitai help to get help.

Additionally, you can add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.

CodeRabbit Configration File (.coderabbit.yaml)

• You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
• The JSON schema for the configuration file is available here.
• If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/coderabbit-overrides.v2.json

CodeRabbit Discord Community

Join our Discord Community to get help, request features, and share feedback.

[coderabbitai]

Review Status

Actionable comments generated: 3

Configuration used: CodeRabbit UI

Commits

Files that changed from the base of the PR and between 9b58e1a and a7816b9.

Files selected for processing (7)

• Data/Data/Repository/ShareCodeRepository.swift (1 hunks)
• Data/Data/Repository/UserRepository.swift (4 hunks)
• Splito/UI/Home/Groups/Add Member/JoinMemberViewModel.swift (1 hunks)
• Splito/UI/Login/PhoneLogin/VerifyOtp/VerifyOtpViewModel.swift (1 hunks)
• Splito/UI/Onboard/OnboardRouteView.swift (1 hunks)
• install_dist_certs.sh (1 hunks)
• install_dist_profile.sh (1 hunks)

Files skipped from review due to trivial changes (1)

• install_dist_certs.sh

Additional comments: 3

Data/Data/Repository/UserRepository.swift (1)

• 34-41: > 📝 NOTE

This review was outside the diff hunks and was mapped to the diff hunk with the greatest overlap. Original lines [16-51]

The modifications to the storeUser function to return an AppUser object and the improvements in logging practices are commendable. These changes enhance the method's utility and streamline the logging process. Ensure that the changes in logging levels from error to debug for certain events are appropriate and consider documenting the rationale behind these changes for future reference.

Splito/UI/Home/Groups/Add Member/JoinMemberViewModel.swift (1)

• 51-65: The implementation of the addMemberIfCodeExists method is a crucial addition for ensuring that members are added only if the code is valid. The logic appears sound, but consider reviewing the date comparison for accuracy, especially regarding time zones if applicable. Additionally, the deletion of the shared code after adding the member is a good practice to prevent reuse.

Splito/UI/Login/PhoneLogin/VerifyOtp/VerifyOtpViewModel.swift (1)

• 121-123: Moving the assignment of self.preference.user within the receiveValue closure and adding a check for self are excellent practices for ensuring the weak self reference is valid and for improving the robustness of the code. These changes are in line with best practices for handling asynchronous closures in Swift and help prevent potential crashes due to null references.

[coderabbitai]

Review Status

Actionable comments generated: 1

Configuration used: CodeRabbit UI

Commits

Files that changed from the base of the PR and between a7816b9 and ef07391.

Files ignored due to path filters (3)

• Podfile.lock is excluded by !**/*.lock
• Splito/Resource/Assets.xcassets/Images/Setting/CheckMarkTick.imageset/CheckMark.png is excluded by !**/*.png
• Splito/Resource/Assets.xcassets/Images/Setting/CheckMarkTick.imageset/Contents.json is excluded by !**/*.json

Files selected for processing (24)

• BaseStyle/BaseStyle.xcodeproj/project.pbxproj (4 hunks)
• Data/Data.xcodeproj/project.pbxproj (9 hunks)
• Data/Data/Model/Expense.swift (1 hunks)
• Data/Data/Repository/ExpenseRepository.swift (1 hunks)
• Data/Data/Repository/GroupRepository.swift (1 hunks)
• Data/Data/Repository/MemberRepository.swift (1 hunks)
• Data/Data/Repository/ShareCodeRepository.swift (2 hunks)
• Data/Data/Router/AppRoute.swift (2 hunks)
• Data/Data/Store/MemberStore.swift (1 hunks)
• Podfile (1 hunks)
• Splito.xcodeproj/project.pbxproj (13 hunks)
• Splito/UI/Home/Expense/AddExpenseView.swift (1 hunks)
• Splito/UI/Home/Expense/AddExpenseViewModel.swift (1 hunks)
• Splito/UI/Home/Expense/Detail Selection/ChooseGroupView.swift (1 hunks)
• Splito/UI/Home/Expense/Detail Selection/ChooseGroupViewModel.swift (1 hunks)
• Splito/UI/Home/Expense/Detail Selection/ChoosePayerView.swift (1 hunks)
• Splito/UI/Home/Expense/Detail Selection/ChoosePayerViewModel.swift (1 hunks)
• Splito/UI/Home/Expense/ExpenseRouteView.swift (1 hunks)
• Splito/UI/Home/Groups/Create Group/CreateGroupView.swift (1 hunks)
• Splito/UI/Home/Groups/Create Group/CreateGroupViewModel.swift (1 hunks)
• Splito/UI/Home/Groups/GroupListViewModel.swift (2 hunks)
• Splito/UI/Home/Groups/GroupRouteView.swift (1 hunks)
• Splito/UI/Home/HomeRouteView.swift (3 hunks)
• install_dist_profile.sh (1 hunks)

Files skipped from review due to trivial changes (3)

• BaseStyle/BaseStyle.xcodeproj/project.pbxproj
• Data/Data/Repository/ExpenseRepository.swift
• Podfile

Additional comments (30)

install_dist_profile.sh (2)

• 12-12: The addition of double quotes around variables is a good practice to prevent issues with spaces and special characters in file paths. Well done!
• 18-18: The modification to include the -- option in the rm command enhances safety and accuracy. Good practice!

Splito/UI/Home/Expense/ExpenseRouteView.swift (1)

• 12-26: The implementation of ExpenseRouteView follows SwiftUI conventions and is well-structured. The use of @StateObject for routing and the switch case within the RouterView are correctly implemented. Good job!

Data/Data/Repository/MemberRepository.swift (2)

• 31-33: The implementation of the fetchMembers function correctly uses the Combine framework for asynchronous data fetching. Good practice!
• 35-37: The fetchMembersByGroup function is correctly implemented, adhering to the Combine framework's conventions for asynchronous data fetching by group ID. Well done!

Splito/UI/Home/Groups/GroupRouteView.swift (1)

• 17-30: The direct embedding of RouterView in the body, without the VStack container, simplifies the layout structure and is consistent with SwiftUI's composability principles. Good simplification!

Data/Data/Model/Expense.swift (1)

• 10-42: The Expense model is well-defined, with appropriate properties and correct use of @DocumentID for Firestore ID generation. The custom CodingKeys and the SplitType enum are also well-implemented. Good job!

Data/Data/Repository/ShareCodeRepository.swift (1)

• 12-12: The addition of CODE_EXPIRATION_LIMIT with a clear comment is good practice. If there's a possibility that the expiration limit might change based on different environments or requirements, consider making this value configurable through a settings file or environment variable for enhanced flexibility.

Splito/UI/Home/Expense/Detail Selection/ChoosePayerViewModel.swift (1)

• 11-53: The implementation of ChoosePayerViewModel is well-structured, adhering to MVVM principles. The use of @Published properties for reactive UI updates, the handling of view states through the ViewState enum, and the use of [weak self] in closures to prevent retain cycles are all correctly implemented. Good job!

Data/Data/Router/AppRoute.swift (1)

• 33-34: Adding the AddExpenseView case to the AppRoute enum is a straightforward way to handle navigation related to expense management. This addition seems well-integrated with the existing navigation structure.

Splito/UI/Home/Expense/Detail Selection/ChooseGroupViewModel.swift (1)

• 11-51: The ChooseGroupViewModel is well-structured, with clear separation of concerns and proper use of Combine for asynchronous data fetching. The use of @Published properties for reactive UI updates and the inclusion of a custom ViewState enum for managing UI states are commendable practices.

Splito/UI/Home/Groups/GroupListViewModel.swift (2)

• 46-46: The update to directly set groupListState based on the presence of groups simplifies the logic and improves readability. This change makes the state management more straightforward.
• 83-83: Removing the groups parameter from the hasGroup case in the GroupListState enum aligns with the simplified logic in the fetchGroups function. However, ensure that this change does not impact any UI components that might rely on the groups data being directly available from the state.

Verification successful

---

The search results indicate that the GroupListState enum, specifically the hasGroup case, does not show direct usage in a way that would impact UI components negatively due to the removal of the groups parameter. The references found are limited to the declaration and usage within GroupListViewModel.swift itself, with no evidence of direct impact on UI components. Based on this evidence, it appears that the initial concern about UI components being negatively impacted may be unfounded.

Scripts Executed

The following scripts were executed for the analysis:

---

Script:

#!/bin/bash
# Verify that no UI components are negatively impacted by the removal of the `groups` parameter from the `hasGroup` case.
rg "groupListState\.hasGroup" --type swift

Length of output: 44

---

---

Script:

#!/bin/bash
# Broaden the search to find any usage of the GroupListState enum to ensure no UI components are impacted indirectly.
rg "GroupListState" --type swift

Length of output: 385

Splito/UI/Home/HomeRouteView.swift (3)

• 14-14: The addition of the openExpenseSheet state variable to manage the visibility of an expense sheet is a clean way to handle modal presentation in SwiftUI. This approach keeps the UI logic simple and declarative.
• 31-32: Replacing HomeView with InvisibleView for the second tab item is an interesting approach to hide a tab item while preserving the tab bar layout. This technique can be useful in scenarios where conditional navigation is required.
• 47-66: Updating the CenterFabButton to handle the onclick action and show ExpenseRouteView in full screen when the button is clicked enhances the user experience by providing a clear entry point for adding expenses. The implementation is straightforward and integrates well with the existing UI structure.

Splito/UI/Home/Expense/Detail Selection/ChoosePayerView.swift (1)

• 1-34: The ChoosePayerView is implemented with a clear and concise UI structure, focusing on the essential elements needed for the payer selection process. The use of environment values for dismissal and the inclusion of a toolbar for navigation actions are in line with SwiftUI best practices.

Splito/UI/Home/Expense/Detail Selection/ChooseGroupView.swift (2)

• 13-52: The ChooseGroupView effectively handles different view states (loading, success) and provides a user-friendly interface for selecting a group. The use of ScrollView and LazyVStack for listing groups is appropriate for performance and usability.
• 55-94: The GroupCellView is well-designed, offering a visually appealing way to present group information. The conditional rendering of the checkmark image for the selected group enhances the user experience by providing clear feedback on selection.

Splito/UI/Home/Groups/Create Group/CreateGroupViewModel.swift (1)

• 90-90: Capitalizing the groupName before creating a new Groups instance is a thoughtful detail that ensures consistency in group names across the application. This minor change improves the data quality and user experience.

Splito/UI/Home/Groups/Create Group/CreateGroupView.swift (1)

• 57-68: Replacing navigationBarItems with a toolbar for the "Done" button in CreateGroupView aligns with SwiftUI's modern approach to handling navigation bar items. The use of .toolbar provides a more flexible and consistent way to manage navigation bar content across different iOS versions.

Data/Data/Store/MemberStore.swift (2)

• 75-106: Consider refining error handling and logging within fetchMembers() to provide more specific feedback for different error types. For instance, distinguishing between network errors and decoding errors in the logs could help with debugging and maintenance.
• 108-142: Similar to fetchMembers(), consider refining error handling and logging within fetchMembersByGroup(id: String) to provide more specific feedback for different error types. This could improve the maintainability and debuggability of the code.

Splito/UI/Home/Expense/AddExpenseView.swift (2)

• 55-60: The "Save" button currently only dismisses the view. Consider implementing the functionality to actually save the expense data when this button is tapped.
• 66-164: The subviews ExpenseDetailRow, GroupSelectionView, and PaidByView are well-implemented and follow SwiftUI best practices. Good job on keeping the code clean and readable.

Data/Data/Repository/GroupRepository.swift (1)

• 200-214: Consider refining error handling and logging within fetchGroups to provide more specific feedback for different error types. This could help with debugging and maintenance by making it easier to identify the source of errors.

Data/Data.xcodeproj/project.pbxproj (2)

• 14-14: The addition of Expense.swift to the project file is correctly done, ensuring it's properly referenced and included in the build phase.

Also applies to: 61-61, 493-493

• 15-15: The addition of ExpenseRepository.swift to the project file is correctly done, ensuring it's properly referenced and included in the build phase.

Also applies to: 62-62, 487-487

Splito.xcodeproj/project.pbxproj (2)

• 15-21: The addition of new Swift files related to expense management (AddExpenseView.swift, AddExpenseViewModel.swift, ExpenseRouteView.swift, ChoosePayerView.swift, ChoosePayerViewModel.swift, ChooseGroupView.swift, and ChooseGroupViewModel.swift) is correctly integrated into the project structure. Each file is properly referenced in the PBXBuildFile, PBXFileReference, and PBXGroup sections, ensuring they are included in the build process and project navigator.
• 890-890: The deployment target is set to iOS 16.4 for all configurations. Ensure this high minimum requirement aligns with your intended audience and feature dependencies. If broader compatibility is desired, consider lowering the deployment target, keeping in mind the features and APIs used in the app.

Also applies to: 947-947, 981-981, 1085-1085, 1176-1176, 1198-1198

[coderabbitai]

Review Status

Actionable comments generated: 0

Configuration used: CodeRabbit UI

Commits

Files that changed from the base of the PR and between ef07391 and ba1ff01.

Files selected for processing (12)

• Data/Data.xcodeproj/project.pbxproj (14 hunks)
• Data/Data/DI/AppAssembly.swift (2 hunks)
• Data/Data/Model/Expense.swift (1 hunks)
• Data/Data/Model/Groups.swift (1 hunks)
• Data/Data/Repository/GroupRepository.swift (2 hunks)
• Splito/UI/Home/Expense/AddExpenseViewModel.swift (1 hunks)
• Splito/UI/Home/Expense/Detail Selection/ChooseGroupView.swift (1 hunks)
• Splito/UI/Home/Expense/Detail Selection/ChooseGroupViewModel.swift (1 hunks)
• Splito/UI/Home/Expense/Detail Selection/ChoosePayerViewModel.swift (1 hunks)
• Splito/UI/Home/Groups/Add Member/JoinMemberViewModel.swift (2 hunks)
• Splito/UI/Home/Groups/Create Group/CreateGroupView.swift (1 hunks)
• Splito/UI/Home/Groups/Create Group/CreateGroupViewModel.swift (2 hunks)

Files skipped from review as they are similar to previous changes (9)

• Data/Data.xcodeproj/project.pbxproj
• Data/Data/Model/Expense.swift
• Data/Data/Repository/GroupRepository.swift
• Splito/UI/Home/Expense/AddExpenseViewModel.swift
• Splito/UI/Home/Expense/Detail Selection/ChooseGroupView.swift
• Splito/UI/Home/Expense/Detail Selection/ChooseGroupViewModel.swift
• Splito/UI/Home/Expense/Detail Selection/ChoosePayerViewModel.swift
• Splito/UI/Home/Groups/Create Group/CreateGroupView.swift
• Splito/UI/Home/Groups/Create Group/CreateGroupViewModel.swift

Additional comments (4)

Data/Data/Model/Groups.swift (2)

• 16-16: The change in the members property type from an array of Member objects to an array of String objects simplifies the data model. Ensure that all functionalities relying on members are updated to work with member identifiers instead of full Member objects.
• 20-20: Ensure that all calls to the Groups initializer are updated to pass an array of String objects for members, aligning with the updated property type.

Data/Data/DI/AppAssembly.swift (1)

• 39-44: > 📝 NOTE

This review was outside the diff hunks, and no overlapping diff hunk was found. Original lines [1-1]

The removal of MemberStore and MemberRepository from the dependency injection setup simplifies the configuration. Ensure that all parts of the application that previously relied on these dependencies are updated accordingly and that the removal aligns with the application's architectural evolution.

Splito/UI/Home/Groups/Add Member/JoinMemberViewModel.swift (1)

• 50-64: The refactor of addMember to addMemberIfCodeExists introduces robust handling of code expiration. Ensure that the logic is well-documented with comments for clarity and that all related functionalities are thoroughly tested to prevent issues with adding members using shared codes.

[coderabbitai]

Actionable comments posted: 0

Review Status

Configuration used: CodeRabbit UI

Commits

Files that changed from the base of the PR and between ba1ff01 and 8f15815.

Files selected for processing (19)

• Data/Data/Repository/GroupRepository.swift (2 hunks)
• Data/Data/Repository/ShareCodeRepository.swift (2 hunks)
• Data/Data/Repository/UserRepository.swift (1 hunks)
• Splito/UI/BaseViewModel.swift (1 hunks)
• Splito/UI/Home/Expense/AddExpenseView.swift (1 hunks)
• Splito/UI/Home/Expense/AddExpenseViewModel.swift (1 hunks)
• Splito/UI/Home/Expense/Detail Selection/ChooseGroupView.swift (1 hunks)
• Splito/UI/Home/Expense/Detail Selection/ChooseGroupViewModel.swift (1 hunks)
• Splito/UI/Home/Expense/Detail Selection/ChoosePayerView.swift (1 hunks)
• Splito/UI/Home/Expense/Detail Selection/ChoosePayerViewModel.swift (1 hunks)
• Splito/UI/Home/Groups/Add Member/InviteMemberViewModel.swift (1 hunks)
• Splito/UI/Home/Groups/Add Member/JoinMemberViewModel.swift (2 hunks)
• Splito/UI/Home/Groups/Create Group/CreateGroupViewModel.swift (3 hunks)
• Splito/UI/Home/Groups/Group/GroupHomeViewModel.swift (1 hunks)
• Splito/UI/Home/Groups/GroupListViewModel.swift (2 hunks)
• Splito/UI/Login/LoginViewModel.swift (1 hunks)
• Splito/UI/Login/PhoneLogin/VerifyOtp/VerifyOtpViewModel.swift (1 hunks)
• Splito/UI/User Profile/UserProfileView.swift (3 hunks)
• Splito/UI/User Profile/UserProfileViewModel.swift (2 hunks)

Files skipped from review due to trivial changes (4)

• Splito/UI/BaseViewModel.swift
• Splito/UI/Home/Groups/Group/GroupHomeViewModel.swift
• Splito/UI/Login/LoginViewModel.swift
• Splito/UI/User Profile/UserProfileView.swift

Files skipped from review as they are similar to previous changes (10)

• Data/Data/Repository/GroupRepository.swift
• Data/Data/Repository/ShareCodeRepository.swift
• Splito/UI/Home/Expense/AddExpenseView.swift
• Splito/UI/Home/Expense/AddExpenseViewModel.swift
• Splito/UI/Home/Expense/Detail Selection/ChooseGroupView.swift
• Splito/UI/Home/Expense/Detail Selection/ChooseGroupViewModel.swift
• Splito/UI/Home/Expense/Detail Selection/ChoosePayerViewModel.swift
• Splito/UI/Home/Groups/Add Member/JoinMemberViewModel.swift
• Splito/UI/Home/Groups/Create Group/CreateGroupViewModel.swift
• Splito/UI/Home/Groups/GroupListViewModel.swift

Additional Context Used

Additional comments not posted (7)

Splito/UI/Home/Groups/Add Member/InviteMemberViewModel.swift (1)

55-55: The change from cancelables to cancelable in the fetchGroup method aligns with a more focused management of cancellable subscriptions. Ensure that this change is consistently applied across the entire ViewModel where applicable. This approach can help in preventing memory leaks and managing subscriptions more effectively.

Data/Data/Repository/UserRepository.swift (3)

16-37: The refactoring of the storeUser method to return a publisher of AppUser instead of Void enhances the method's usability by providing feedback on the operation's outcome. The use of flatMap for handling user existence checks and the improved error handling and logging practices are commendable. Ensure that the error messages are clear and informative for easier debugging and maintenance.

---

39-48: The addition of the fetchUserBy method to fetch a user by ID is a valuable enhancement. It uses a clear and concise approach to filter users and handle errors. Ensure that error logging provides enough context for debugging and that the method's usage is consistent with the application's data fetching patterns.

---

14-14: The renaming of cancelables to cancelable suggests a more focused approach to managing cancellable subscriptions. This change should be consistently applied across the class to ensure effective subscription management and prevent memory leaks.

Splito/UI/Home/Expense/Detail Selection/ChoosePayerView.swift (1)

1-124: The ChoosePayerView SwiftUI view is well-structured and makes effective use of SwiftUI constructs and third-party libraries like Kingfisher for image loading. Ensure that images are cached effectively to improve performance and that the list rendering is optimized for larger datasets. Consider adding comments to complex UI logic for better maintainability.

Splito/UI/Login/PhoneLogin/VerifyOtp/VerifyOtpViewModel.swift (1)

121-125: The changes in the storeUser method, specifically capturing the user parameter directly in the receiveValue closure, streamline the login process by setting the preference.user before calling onLoginSuccess(). This approach enhances the clarity and efficiency of the login flow. Ensure that the storeUser method's error handling is robust and that the user experience is smooth in case of login failures.

Splito/UI/User Profile/UserProfileViewModel.swift (1)

127-127: The change from cancelables to cancelable in the updateUserProfile and handleDeleteAction methods aligns with a more focused management of cancellable subscriptions. This approach can help in preventing memory leaks and managing subscriptions more effectively. Ensure that this change is consistently applied across the entire ViewModel where applicable.

[coderabbitai]

Actionable comments posted: 0

Review Status

Configuration used: CodeRabbit UI

Commits

Files that changed from the base of the PR and between 8f15815 and 90aac1b.

Files selected for processing (3)

• Splito/UI/Home/Expense/AddExpenseView.swift (1 hunks)
• Splito/UI/Home/Expense/AddExpenseViewModel.swift (1 hunks)
• Splito/UI/Home/Expense/Detail Selection/ChoosePayerView.swift (1 hunks)

Files skipped from review as they are similar to previous changes (3)

• Splito/UI/Home/Expense/AddExpenseView.swift
• Splito/UI/Home/Expense/AddExpenseViewModel.swift
• Splito/UI/Home/Expense/Detail Selection/ChoosePayerView.swift

Additional Context Used

[coderabbitai]

Actionable comments posted: 0

Review Status

Configuration used: CodeRabbit UI

Commits

Files that changed from the base of the PR and between 90aac1b and 0af6414.

Files selected for processing (11)

• Data/Data.xcodeproj/project.pbxproj (15 hunks)
• Data/Data/DI/AppAssembly.swift (3 hunks)
• Data/Data/Model/Expense.swift (1 hunks)
• Data/Data/Repository/ExpenseRepository.swift (1 hunks)
• Data/Data/Repository/GroupRepository.swift (2 hunks)
• Data/Data/Store/ExpenseStore.swift (1 hunks)
• Data/Data/Store/GroupStore.swift (2 hunks)
• Data/Data/Store/ShareCodeStore.swift (1 hunks)
• Splito/UI/Home/Expense/AddExpenseView.swift (1 hunks)
• Splito/UI/Home/Expense/AddExpenseViewModel.swift (1 hunks)
• Splito/UI/Home/HomeRouteView.swift (1 hunks)

Files skipped from review as they are similar to previous changes (7)

• Data/Data.xcodeproj/project.pbxproj
• Data/Data/DI/AppAssembly.swift
• Data/Data/Model/Expense.swift
• Data/Data/Repository/ExpenseRepository.swift
• Splito/UI/Home/Expense/AddExpenseView.swift
• Splito/UI/Home/Expense/AddExpenseViewModel.swift
• Splito/UI/Home/HomeRouteView.swift

Additional Context Used

Additional comments not posted (10)

Data/Data/Store/ShareCodeStore.swift (1)

60-60: The modification in the deleteSharedCode method, which removes the return statement before the Future declaration, follows Swift best practices for cleaner and more readable code.

Data/Data/Store/ExpenseStore.swift (3)

17-26: Ensure that Firestore operations and the completion handler in the addExpense method are executed on the appropriate threads, especially if this affects the UI.

---

28-60: The fetchExpensesBy method correctly handles Firestore operations and error scenarios. Ensure to test cases where the documents might be empty to verify the expected behavior.

---

62-79: The deleteExpense method is implemented correctly, with proper error handling and logging. Ensure to test various deletion scenarios, including attempts to delete non-existent documents.

Data/Data/Store/GroupStore.swift (1)

56-64: > 📝 NOTE

This review was outside the diff hunks and was mapped to the diff hunk with the greatest overlap. Original lines [45-61]

The modifications in the fetchGroups method simplify its usage and adjust error handling. Ensure to verify the impact on any functionality that previously relied on fetching groups specific to a user.

Data/Data/Repository/GroupRepository.swift (5)

18-49: The createGroup method is implemented correctly, with proper error handling and asynchronous image upload logic. Ensure to verify that image uploads are performed on an appropriate thread to avoid blocking the UI.

---

51-53: The fetchGroupBy method correctly delegates fetching logic to the GroupStore, maintaining separation of concerns.

---

55-69: The updated fetchGroups method introduces filtering based on user membership. Ensure to thoroughly test this logic with various user scenarios to confirm correct functionality.

---

72-82: The addMemberToGroup method correctly handles adding a member to a group. Ensure to handle scenarios where the specified group does not exist.

---

110-111: The updateGroup method correctly delegates update logic to the GroupStore, maintaining separation of concerns.

[coderabbitai]

Actionable comments posted: 0

Review Status

Configuration used: CodeRabbit UI

Commits

Files that changed from the base of the PR and between 0af6414 and 85f358c.

Files selected for processing (1)

• Splito/UI/Home/Expense/AddExpenseView.swift (1 hunks)

Files skipped from review as they are similar to previous changes (1)

• Splito/UI/Home/Expense/AddExpenseView.swift

Additional Context Used