✨ (dashboards) ability to save filters & timeframes on spending widgets #3432
Conversation
actual-github-bot
bot
changed the title
✅ Deploy Preview for actualbudget ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
Bundle Stats — desktop-clientHey there, this message comes from a GitHub action that helps you and reviewers to understand how these changes affect the size of this project's bundle. As this PR is updated, I'll keep you updated on how the bundle size is impacted. Total
Changeset
View detailed bundle breakdownAdded No assets were added Removed No assets were removed Bigger
Smaller No assets were smaller Unchanged
|
Bundle Stats — loot-coreHey there, this message comes from a GitHub action that helps you and reviewers to understand how these changes affect the size of this project's bundle. As this PR is updated, I'll keep you updated on how the bundle size is impacted. Total
Changeset No files were changed View detailed bundle breakdownAdded No assets were added Removed No assets were removed Bigger No assets were bigger Smaller No assets were smaller Unchanged
|
MatissJanis
changed the title
/ed/ removed incorrect info (see Carkom's comment below) |
|
@Teprifer you are not using the most up-to-date version of edge. |
|
@carkom Doh! I'd updated but not refreshed enough -.- Thanks for the heads up. |
|
Fatal Error found:
|
| options={[ | ||
| ...(reportMode === 'single-month' | ||
| ? [] | ||
| : [['current-month', t('Current Month')] as const]), |
There was a problem hiding this comment.
I'd suggest we remove the actual current month from the list so it's not duplicated. Could we also offer a "last month" option in the "to" selection and create a "live" graph when "single month" button is chosen?
There was a problem hiding this comment.
I actually removed the notion of "current month" and instead aligned the functionality with the other reports to have a more consistent interface. It did seem like a good idea in the beginning to use the "current month" label, but it actually has a fair few complexities that I hadn't considered. Maybe we will bring it back in a future revision. But for now - no.
--
Added the "live/static" button.
|
@MatissJanis - the calculateTimeRange is not handling reversed dates. Not sure how it should handle them but current functionality is not very intuitive. I guess just an absolute value for the "month difference"?
It's also making the "CompareTo" (which is saved as "end" in the code and the dotted gray line in the graph) equal to the current month which is not the intended function. Current month should be green in a live graph. Seems like the calculateTimeRange is giving you "start" and "end" in reverse order. |
WalkthroughThe pull request introduces modifications across several components in the desktop client. Key updates include the addition of a new optional property for customizing popover styling in the Changes
Possibly related PRs
Suggested labels
Recent review detailsConfiguration used: CodeRabbit UI Files selected for processing (1)
Files skipped from review as they are similar to previous changes (1)
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? 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 (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
Outside diff range and nitpick comments (1)
packages/desktop-client/src/components/reports/reports/Spending.tsx (1)
Line range hint
63-584: Consider breaking down the UI rendering logic into smaller components.The function is using the
useFilters,useReport,useNavigate, anduseResponsivehooks for state management, data fetching, navigation, and responsive design, which are good practices. However, the UI rendering logic is quite complex and could be broken down into smaller components for better readability and maintainability.
Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files ignored due to path filters (1)
upcoming-release-notes/3432.mdis excluded by!**/*.md
Files selected for processing (12)
- packages/desktop-client/src/components/common/Select.tsx (3 hunks)
- packages/desktop-client/src/components/reports/DateRange.tsx (1 hunks)
- packages/desktop-client/src/components/reports/Header.tsx (1 hunks)
- packages/desktop-client/src/components/reports/Overview.tsx (1 hunks)
- packages/desktop-client/src/components/reports/ReportRouter.tsx (1 hunks)
- packages/desktop-client/src/components/reports/graphs/SpendingGraph.tsx (8 hunks)
- packages/desktop-client/src/components/reports/reports/Spending.tsx (8 hunks)
- packages/desktop-client/src/components/reports/reports/SpendingCard.tsx (4 hunks)
- packages/desktop-client/src/components/reports/spreadsheets/spending-spreadsheet.ts (0 hunks)
- packages/loot-core/src/types/models/dashboard.d.ts (1 hunks)
- packages/loot-core/src/types/models/reports.d.ts (0 hunks)
- packages/loot-core/src/types/prefs.d.ts (0 hunks)
Files not reviewed due to no reviewable changes (3)
- packages/desktop-client/src/components/reports/spreadsheets/spending-spreadsheet.ts
- packages/loot-core/src/types/models/reports.d.ts
- packages/loot-core/src/types/prefs.d.ts
Additional comments not posted (20)
packages/desktop-client/src/components/reports/ReportRouter.tsx (1)
20-20: LGTM! The new route aligns with the PR objective.The addition of the
/spending/:idroute with a dynamic:idparameter enables rendering theSpendingcomponent for specific spending reports. This change supports the PR objective of allowing users to save individual spending widgets within dashboards, as each saved widget would have a unique identifier.The implementation looks good and does not appear to negatively impact existing functionality.
packages/desktop-client/src/components/reports/DateRange.tsx (1)
65-70: LGTM!The new
else ifblock correctly handles the rendering logic for 'budget' and 'average' types. It formats thestartDateand displays the appropriate comparison text, enhancing the component's functionality and user experience.packages/loot-core/src/types/models/dashboard.d.ts (1)
44-50: LGTM! The changes enhance the functionality and versatility of theSpendingWidget.The addition of the new optional properties (
conditions,conditionsOp,timeFrame, andmode) allows for more detailed and customizable representations of spending data:
conditionsandconditionsOpenable more complex filtering or criteria to be applied to the spending data.timeFrameintroduces a temporal aspect to the widget, allowing it to be configured for different periods.modeprovides the ability for the widget to operate in different contexts, such as 'single-month', 'budget', or 'average'.The breaking change is justified given the experimental nature of the feature, as mentioned in the PR objectives. The refactoring effort to transition from
LocalPrefsto a widget-based approach seems to be a step towards a more modular and maintainable codebase.packages/desktop-client/src/components/common/Select.tsx (2)
29-29: LGTM!The new optional
popoverStyleproperty enhances the flexibility of theSelectcomponent by allowing custom styles for the popover. The typeCSSPropertiesis correctly imported and used. This change doesn't introduce any breaking changes or issues.
55-55: LGTM!The
popoverStyleprop is correctly destructured with a default value of an empty object, ensuring that existing code will continue to work without any issues. Applying thepopoverStyleprop to thestyleattribute of thePopovercomponent allows custom styles to be applied when the popover is rendered. These changes are consistent with the addition of thepopoverStyleproperty to theSelectPropstype and don't introduce any breaking changes or issues.Also applies to: 116-116
packages/desktop-client/src/components/reports/reports/SpendingCard.tsx (5)
26-26: LGTM!The
widgetIdprop is a valid addition to theSpendingCardPropstype.
34-36: LGTM!The destructuring of the
widgetIdprop and the default value assignment for themetaprop are valid changes.
40-46: LGTM!The variable assignments for
isDashboardsFeatureEnabled,start,end, andspendingReportModeare valid and consistent with the provided context.
51-59: LGTM!The variable assignments for
selectionandgetGraphDataare valid and consistent with the provided context. The use ofuseMemofor memoizing thegetGraphDatafunction is a good optimization.
Line range hint
63-169: LGTM!The variable assignments, conditional rendering, and the use of the
DateRange,SpendingGraph, andLoadingIndicatorcomponents are all valid and consistent with the provided context.packages/desktop-client/src/components/reports/Header.tsx (1)
76-76: Verify the impact of removing the'/reports/spending'condition.The change in the conditional rendering logic removes the check for
'/reports/spending'path. This means that theViewcomponent will now be rendered for any path other than'/reports/custom'.Please clarify the intention behind this change and verify if it aligns with the expected user interface behavior for different report paths. Ensure that removing the
'/reports/spending'condition does not lead to any unintended consequences.To verify the impact, run the following script:
Verification successful
The removal of '/reports/spending' condition appears intentional and beneficial.
After verifying the codebase, it's clear that the change in
Header.tsxallows the View component to be rendered for all report paths except '/reports/custom'. This includes '/reports/spending', '/reports/net-worth', and '/reports/cash-flow'.The impact of this change is that it simplifies the conditional logic and provides consistent behavior across different report types. It doesn't introduce any issues with existing functionality.
To make the code more explicit and easier to maintain, you might consider using a constant for the excluded path:
const CUSTOM_REPORT_PATH = '/reports/custom'; // ... {!path.includes(CUSTOM_REPORT_PATH) && ( // View component )}This change enhances readability and allows for easier updates if more paths need to be excluded in the future.
Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the rendering behavior for different report paths. # Test: Search for the usage of `'/reports/spending'` path. # Expect: Occurrences in other components that might be impacted by this change. rg --type typescript $'/reports/spending' # Test: Search for the usage of other report paths (excluding custom and spending). # Expect: Occurrences of other report paths to verify the rendering behavior. rg --type typescript $'/reports/(?!custom|spending)\w+'Length of output: 376
Script:
#!/bin/bash # Description: Verify the rendering behavior for different report paths. # Search for the usage of '/reports/spending' path rg --type ts '/reports/spending' # Search for the usage of '/reports/custom' path rg --type ts '/reports/custom' # Search for other report paths rg --type ts '/reports/\w+' # Search for conditional rendering related to report paths ast-grep --lang typescript --pattern 'path.includes("/reports/")' # Search for Switch or conditional statements related to report paths ast-grep --lang typescript --pattern 'switch ($path) { $$$ case "/reports/$_": $$$ }'Length of output: 3398
packages/desktop-client/src/components/reports/graphs/SpendingGraph.tsx (5)
35-41: LGTM!The change to the
monthsproperty in thePayloadItemtype provides more flexibility by allowing a dynamic set of month entries. This is a good improvement to the data structure.
48-49: LGTM!The changes to the
balanceTypeOpandselectionproperties in theCustomTooltipPropstype enforce stricter typing. This improves the clarity of the expected values and reduces the risk of incorrect usage. Good job on enhancing the type safety!
65-65: LGTM!The addition of optional chaining (
?.) in several places improves the robustness of the code by safely accessing properties that may not exist in themonthsobject. This prevents potential runtime errors. Nice work on handling the optional properties gracefully!Also applies to: 88-88, 92-92, 108-108, 112-112
128-128: LGTM!The change to the
modeproperty in theSpendingGraphPropstype enforces stricter typing and improves clarity. The adjustments to thethisMonthMaxandselectionMaxlogic ensure that the code remains robust against undefined values. These changes enhance the type safety and reliability of the code. Well done!Also applies to: 144-158
161-167: LGTM!The explicit type definition for the tick formatter enhances type safety for the tick formatting function. This is a good practice to ensure that the function receives and returns the expected types. Nice work on improving the type safety!
packages/desktop-client/src/components/reports/Overview.tsx (1)
548-548: Excellent addition of thewidgetIdprop to support saving spending widgets!The
widgetIdprop, set to the unique identifieritem.i, is a crucial change that enables theSpendingCardcomponent to manage its state and settings based on the widget instance. This aligns perfectly with the PR objective of transitioning fromLocalPrefsto a widget-based approach for saving spending widgets within dashboards.packages/desktop-client/src/components/reports/reports/Spending.tsx (3)
45-57: LGTM!The function is using the
useParamshook to retrieve the widget ID from the URL and theuseWidgethook to fetch the spending widget data, which are good practices for dynamic routing and data fetching. It also handles the loading state by displaying aLoadingIndicatorwhile the widget data is being fetched, which is a good practice for user experience.
136-157: LGTM!The
onSaveWidgetfunction is saving the widget settings, which is a good practice for user experience.
37-40: Skipping the review of thecalculateTimeRangefunction.The
calculateTimeRangefunction is imported from an external file and is being used correctly to calculate the start and end dates based on the time frame and mode. Since the function is not defined in this file, it cannot be reviewed in detail.
|
Thanks @carkom ! This has now been fixed: I aligned the date logic between the spending report and the cashflow/networth reports. Also sligthly updated the paddings to better align with the other reports. |
I'm not sure it works like this. There's a couple issues with aligning to network/cashflow.
|
|
@MatissJanis |
There was a problem hiding this comment.
I've left some comments for little nits in the UI function.
There's also a UX bug:
- create new graph
- switch to budgeted mode
- switch to static
- choose a month from a couple months back
- switch back to live
- Save
- Navigate to reports homepage and see that the graph is not live
- Click on graph to see main graph is also not live
packages/desktop-client/src/components/reports/reports/Spending.tsx
Outdated
Show resolved
Hide resolved
packages/desktop-client/src/components/reports/reports/Spending.tsx
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Actionable comments posted: 1
Outside diff range and nitpick comments (6)
packages/desktop-client/src/components/reports/reports/SpendingCard.tsx (2)
26-28: LGTM: Props updated for widget-based approachThe addition of
widgetIdand makingmetaoptional align with the PR objectives. These changes support the transition to a widget-based approach.Consider adding a default value for
metain the prop types to match the default value in the function parameters:meta?: SpendingWidget['meta'] = {};This would make the type definition consistent with the function implementation.
40-46: LGTM: Improved state management and time range calculationThe changes align well with the PR objectives:
- The new
isDashboardsFeatureEnabledflag allows for conditional behavior.- Time range calculation now uses
calculateSpendingReportTimeRange, replacing the previousLocalPrefsapproach.spendingReportModeis now derived from themetaprop, simplifying state management.These updates effectively transition the component to a widget-based approach.
Consider using optional chaining for
meta?.modeto make it consistent with other usages ofmetain the file:const spendingReportMode = meta?.mode ?? 'single-month';packages/desktop-client/src/components/reports/reportRanges.ts (2)
Line range hint
169-194: LGTM! Consider adding a comment for clarity.The changes to
calculateTimeRangelook good. The function now handles reversed dates correctly, addressing the issue mentioned in the PR comments. The use ofPartial<TimeFrame>also improves flexibility.Consider adding a brief comment explaining the logic for handling reversed dates (when start > end). This would improve code readability and maintainability. For example:
if (start > end) { + // Handle reversed date range by swapping start and end return [ monthUtils.currentMonth(), monthUtils.subMonths(monthUtils.currentMonth(), -offset), 'sliding-window', ] as const; }
Line range hint
169-228: Summary: Changes align well with PR objectivesThe modifications to
calculateTimeRangeand the addition ofcalculateSpendingReportTimeRangeeffectively address the requirements for saving spending widgets within dashboards. These changes provide the necessary flexibility for handling different reporting scenarios, including reversed date ranges and various modes (budget, average, single-month).The implementation aligns well with the PR objectives and addresses the issues mentioned in the PR comments, particularly the handling of reversed dates. The transition from using
LocalPrefsto a widget-based approach is evident in these changes.As this feature is still experimental, consider adding comprehensive unit tests to ensure the robustness of these new date handling functions. This will help catch any edge cases and make future refactoring easier as the feature matures.
packages/desktop-client/src/components/reports/reports/Spending.tsx (2)
80-86: Consider refactoring the initialization of compare statesThe
initialCompareandinitialCompareTovariables are used to set the initial state ofcompareandcompareTo, but they are declared after their usage. Consider moving thecalculateSpendingReportTimeRangecall before theuseStatecalls to improve code clarity.- const initialReportMode = widget?.meta?.mode ?? 'single-month'; - const [initialCompare, initialCompareTo] = calculateSpendingReportTimeRange( - widget?.meta ?? {}, - ); - const [compare, setCompare] = useState(initialCompare); - const [compareTo, setCompareTo] = useState(initialCompareTo); + const initialReportMode = widget?.meta?.mode ?? 'single-month'; + const [initialCompare, initialCompareTo] = calculateSpendingReportTimeRange( + widget?.meta ?? {}, + ); + const [compare, setCompare] = useState(initialCompare); + const [compareTo, setCompareTo] = useState(initialCompareTo); const [isLive, setIsLive] = useState(widget?.meta?.isLive ?? true);
Line range hint
1-548: Consider adding comments for complex logic and extracting helper functionsThe Spending component has undergone significant improvements in functionality and user experience. To further enhance maintainability, consider:
- Adding comments to explain complex logic, especially in the rendering section.
- Extracting some of the longer JSX sections into separate components or helper functions to improve readability.
- Adding a brief comment at the top of the file explaining the overall purpose and structure of the component.
These minor improvements will help future developers understand and maintain the code more easily.
Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files selected for processing (4)
- packages/desktop-client/src/components/reports/DateRange.tsx (1 hunks)
- packages/desktop-client/src/components/reports/reportRanges.ts (2 hunks)
- packages/desktop-client/src/components/reports/reports/Spending.tsx (6 hunks)
- packages/desktop-client/src/components/reports/reports/SpendingCard.tsx (4 hunks)
Files skipped from review as they are similar to previous changes (1)
- packages/desktop-client/src/components/reports/DateRange.tsx
Additional comments not posted (10)
packages/desktop-client/src/components/reports/reports/SpendingCard.tsx (6)
19-19: LGTM: New import for report time range calculationThe addition of
calculateSpendingReportTimeRangeimport aligns with the PR objective of transitioning to a widget-based approach. This function likely replaces some functionality previously handled byLocalPrefs.
34-36: LGTM: Function parameters updated for widget-based approachThe addition of
widgetIdparameter and setting a default value formetaare consistent with the updated prop types. These changes support the widget-based approach and ensure the component can work even without meta data.
54-59: LGTM: Graph data calculation updated for widget-based approachThe
getGraphDatafunction and itsuseMemodependencies have been correctly updated to use properties from themetaobject. This change aligns with the transition fromLocalPrefsto a widget-based approach.
87-91: LGTM: Conditional routing for dashboard integrationThe conditional routing based on
isDashboardsFeatureEnabledis a good approach. It allows for seamless integration with the dashboard feature when enabled, while maintaining backwards compatibility. The inclusion ofwidgetIdin the URL when dashboards are enabled supports the new widget-based approach.
169-170: LGTM: Simplified SpendingGraph propsThe
compareandcompareToprops are now directly passed to the SpendingGraph component. This change is consistent with the earlier modifications in time range calculation and simplifies the component's logic.
Line range hint
1-179: Overall: Excellent implementation of widget-based approachThe changes in this file effectively transition the SpendingCard component from using
LocalPrefsto a widget-based approach, aligning perfectly with the PR objectives. Key improvements include:
- Addition of
widgetIdfor unique widget identification.- Transition to using
metafor configuration instead ofLocalPrefs.- Improved time range calculation using
calculateSpendingReportTimeRange.- Conditional routing to support dashboard integration.
- Simplified state management and prop passing.
These changes enhance the component's flexibility and maintainability while preserving backwards compatibility. The code handles the experimental nature of the feature appropriately, using feature flags where necessary.
Great job on implementing these changes! The code is well-structured and effectively addresses the PR objectives.
packages/desktop-client/src/components/reports/reports/Spending.tsx (4)
Line range hint
1-60: Improved component structure and importsThe refactoring of the
Spendingcomponent intoSpendingandSpendingInternalimproves separation of concerns. The addition of new imports, especially theuseWidgethook, suggests better integration with a dashboard feature. This structure will likely enhance maintainability and testability.
61-88: Enhanced state management with widget integrationThe use of the
useWidgethook and initialization of state variables from widget metadata improves the persistence of user preferences. The addition ofisLiveandreportModestates provides more flexibility for users.
Line range hint
134-374: Improved user experience with save functionality and live/static toggleThe addition of the
onSaveWidgetfunction and related UI elements enhances user experience by allowing persistence of preferences. The live/static toggle provides flexibility in data presentation, and the save button tooltip improves user understanding of the feature.
Line range hint
375-548: Enhanced rendering logic with improved flexibility and analytical capabilitiesThe updated rendering logic provides more flexibility and customization options for users. The conditional rendering based on widget data improves the component's adaptability, and the support for different report modes (single-month, budget, average) enhances the analytical capabilities of the component. These changes significantly improve the overall functionality and user experience of the Spending report.
|
Thanks for such diligent testing @carkom ! Should be patched now. |
* marked files for translation * added release note * fixed linting warnings * 🐛 fix account filters being overridden (#3441) *Reduce package size (#3443) * reduce package size of all packages * release notes * Update beforePackHook.ts * [Maintenance] Cleanup react aria packages and dedupe (#3450) * Cleanup react aria packages and dedupe * Release notes * ♻️ (synced-prefs) moving the prefs from metadata.json to the db (#3423) *
Allowing to save spending widgets in dashboards. This required a bit of refactoring to move from
LocalPrefsto widgets.This is a breaking change sadly (i.e. the saved local-pref values will be lost). But IMO that's fine since this is an experimental feature that is expected to have breaking changes.