-
Notifications
You must be signed in to change notification settings - Fork 397
[ui-Quick Start-Analytics] Updating the analytics Frontend code by integrating with new public API and using predefined hooks #4126
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
base: master
Are you sure you want to change the base?
Conversation
✅ Test files were modified. Ensure that the tests cover all relevant changes. ✅ |
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.
Nice work.
5a620d6
to
8d1d537
Compare
0a58cba
to
915f373
Compare
88e988b
to
82e7194
Compare
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.
LGTM
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.
Pull Request Overview
This pull request updates the analytics frontend code to integrate with a new public API for usage analytics settings. The changes replace the old preferences API endpoint with a new usage analytics API and implement modern React patterns using predefined hooks for data management.
Key changes:
- Replaces API endpoint from
/about/update_preferences
to/api/v1/usage_analytics
- Migrates from local state management to
useLoadData
anduseSaveData
hooks - Adds comprehensive error handling and loading states with
LoadingErrorWrapper
Reviewed Changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.
File | Description |
---|---|
Analytics.tsx | Complete refactor to use new API endpoint and modern React hooks for data fetching/saving |
utils.ts | Updates API URL constant to point to new usage analytics endpoint |
api.py | Adds POST method support for the new analytics API (temporary workaround) |
OverviewTab.test.tsx | Extensive test suite updates with new mock configurations and comprehensive test coverage |
Comments suppressed due to low confidence (1)
desktop/core/src/desktop/js/apps/admin/Overview/Analytics.tsx:67
- [nitpick] The function name 'handleAnalyticsCheckboxChange' is redundant since it's already in the Analytics component context. Consider renaming to 'handleCheckboxChange' for brevity and consistency with the previous implementation.
const handleAnalyticsCheckboxChange = (event: React.ChangeEvent<HTMLInputElement>) => {
publish: jest.fn() | ||
})); | ||
|
||
jest.mock( |
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.
Do we really need to mock this?
(post as jest.Mock).mockImplementation(() => | ||
Promise.resolve({ status: 0, message: 'Success' }) | ||
); | ||
}); | ||
|
||
test('fetch and display available apps', async () => { |
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.
We follow it('should
pattern for starting the test case description.
Although test('
is also correct but for consistency lets stick to it('should
expect(post).toHaveBeenCalledWith(USAGE_ANALYTICS_API_URL, data, expectedPostOptions); | ||
}; | ||
|
||
const expectSuccessMessage = (message: string) => { |
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 is no point in creating a function for a single expect.
To maintain consistency in the codebase, write the expected directly in the test.
Same for other expect functions
qsEncodeData: false | ||
}; | ||
|
||
const waitForInitialDataLoad = async () => { |
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.
this function is used only once, why not write the expect of this function directly into renderAnalyticsAndWaitForLoad
await userEvent.click(checkbox); | ||
|
||
await waitFor(() => { | ||
expect(get).toHaveBeenCalledWith(USAGE_ANALYTICS_API_URL, undefined, expectedFetchOptions); |
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.
This get would have been called when the component was loading, too.
Maybe check if the get has been called twice.
One for initial load and one for refetching the data.
What changes were proposed in this pull request?
Updating the analytics Frontend code by integrating with new public API sent by backend which was updated in the PR:
https://github.com/cloudera/hue/pull/4117/files
and #4171
How was this patch tested?
The Analytics unit test has also been modified, manual testing
Updated:
Screen.Recording.2025-07-14.at.2.52.55.PM.mov
Please review Hue Contributing Guide before opening a pull request.