-
Notifications
You must be signed in to change notification settings - Fork 8.1k
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
[Cases] Convert remaining hooks to React Query #157254
Conversation
Pinging @elastic/response-ops (Team:ResponseOps) |
Pinging @elastic/response-ops-cases (Feature:Cases) |
@@ -34,7 +34,6 @@ import { triggersActionsUiMock } from '@kbn/triggers-actions-ui-plugin/public/mo | |||
import { registerConnectorsToMockActionRegistry } from '../../common/mock/register_connectors'; | |||
import { createStartServicesMock } from '../../common/lib/kibana/kibana_react.mock'; | |||
import { waitForComponentToUpdate } from '../../common/test_utils'; | |||
import { useCreateAttachments } from '../../containers/use_create_attachments'; |
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.
not used anymore by the component.
7be43f8
to
81e4cee
Compare
@elasticmachine merge upstream |
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.
Awesome work!! Code looks much cleaner and easy to understand 🎉
I found small issue regarding loading spinner of severity
.
i.e. when I update tag or assignee
, I can see respective loading spinners and severity loading spinner
as well.
loading_severity.mov
commentUpdate: content, | ||
version, | ||
}, | ||
{ |
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.
since we moved handling loadingCommentIds logic out of use_update_comment
hook, Will we have to handle loadingCommentIds everywhere we use patchComment?
I am just wondering what will be the impact if someone uses patchComment somewhere else and doesn't add or remove loadingCommentIds.
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.
That's an excellent question and observation. I think that the use_update_comment
responsibility is to update a comment and that's it. The hooks provide the isLoading
, isFetching
, etc status variables which should be enough. It should not care if it is being used in the user activity. On the other hand, the useUserActionsHandler
is responsible for providing which comment is loading at the moment as it is the one that puts all the pieces together. Does it make sense?
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.
yeah, it makes sense. Currently it's action handler's responsibility to handle comments. And if it changes in future, we can also take care of loadingCommentIds
accordingly.
() => () => { | ||
isCancelledRef.current = true; | ||
abortCtrlRef.current.abort(); | ||
return createAttachments(attachments, request.caseId, abortCtrlRef.signal); |
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.
code looks so clean with react query 😍
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.
Awesome work!! Code looks much cleaner and easy to understand 🎉
I found small issue regarding loading spinner of severity
.
i.e. when I update tag or assignee
, I can see respective loading spinners and severity loading spinner
as well.
loading_severity.mov
I don't see same comment after submission anymore!! 😮 How did you fix this issue? |
Thank you @js-jankisalvi! I can reproduce the issue on main also. If you can also reproduce it on main, can you open an issue so we can address it on another PR? |
Lol, I did not do anything. I don't know what is going on 🤷♀️. Maybe it needs more tries to reproduce it or our hook was buggy and somehow fixed it now. |
Yes, I can reproduce the behaviour in main as well. created issue: #157364 |
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.
verified all mentioned scenarios locally, looks good 👍 🚀
|
@@ -71,7 +71,7 @@ export const AddComment = React.memo( | |||
const editorRef = useRef<EuiMarkdownEditorRef>(null); | |||
const [focusOnContext, setFocusOnContext] = useState(false); | |||
const { permissions, owner, appId } = useCasesContext(); | |||
const { isLoading, createAttachments } = useCreateAttachments(); | |||
const { isLoading, mutate: createAttachments } = useCreateAttachments(); |
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 might have been how it was before these changes, but it seems like other hooks like useUpdateComment
leverages an onError
. Should the calls of createAttachments
do the same?
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.
I think it depends on the scenario. Most of the calls to createAttachments
call mutateAsync
(which is of the form await createAttachments(...)
) and are surrounded by a try/catch. In the scenario of adding a comment I think showing the error toaster (is being automatically by the hook) is enough. Do you have any scenarios in your mind where the onError
is needed?
[] | ||
{ | ||
mutationKey: casesMutationsKeys.pushCase, | ||
onSuccess: (_, { connector }) => { |
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 need to refresh anything once this succeeds?
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.
The refreshing is done by the components that use the hook. But I agree, it should be done by the hook! I will change it.
}, | ||
[] | ||
{ |
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.
When this succeeds is the refresh of the comments done elsewhere so it gets displayed?
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.
So far is being done outside of cases so navigating to cases will refresh the page. We may need to invalidate the caching keys for the case view page. I am not sure, what do you think?
cy.get(TOASTER).should('have.text', "Created 'New connector'"); | ||
cy.get(TOASTER).should('have.text', 'Saved external connection settings'); | ||
cy.get(TOASTER).should('not.exist'); |
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.
Once in a while, the test fails because the toaster disappears and Cypress can not find it. I removed it to reduce flakiness. We verify that the connector is selected properly which I think is enough.
@@ -86,6 +88,15 @@ describe('Cases connectors', () => { | |||
}); | |||
}); | |||
|
|||
after(() => { | |||
cy.request({ |
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.
NIT: Let's wrap this into a more readable method like deleteConnector
and place it in x-pack/plugins/security_solution/cypress/tasks/common.ts
:)
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.
Done in c046e0a
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.
Security changes LGTM. Thanks!
@@ -94,13 +100,10 @@ describe('Cases connectors', () => { | |||
|
|||
cy.wait('@createConnector').then(({ response }) => { | |||
cy.wrap(response?.statusCode).should('eql', 200); | |||
connectorId = response?.body.id ?? ''; |
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.
NIT: This connectorId
does not seem to be used, can we remove it?
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.
Correct. I forgot about it. Done 6655997
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.
D&R changes LGTM
@@ -61,7 +61,8 @@ describe('timeline flyout button', () => { | |||
cy.get(TIMELINE_BOTTOM_BAR_TOGGLE_BUTTON).should('have.focus'); | |||
}); | |||
|
|||
it('the `(+)` button popover menu owns focus', () => { | |||
// FLAKY: https://github.com/elastic/kibana/issues/153771 |
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.
Thank you for the diligence here 👍
💚 Build Succeeded
Metrics [docs]Public APIs missing comments
Async chunks
Public APIs missing exports
Page load bundle
Unknown metric groupsAPI count
ESLint disabled line counts
Total ESLint disabled count
History
To update your PR or re-run it, just comment with: cc @cnasikas |
## Summary This PR converts the remaining cases' hooks to React Query. It also adds the `QueryProvider` to the `CasesProvider` to be able to use the hooks when attaching data to a case from outside cases like ML. Fixes: #134663 ## Testing - Verify you can add a comment successfully and the new comment markdown editor is empty after submission - Verify you can add attachments to a new case and an existing case - Add a file to a case. Verify that the entry in the user activity is being shown - Verify that you can push a case to an external service - Verify that you can push a case to an external service when creating a case - Verify that the loading spinner is being shown when you edit a comment in the actions of the comment - Verify that the loading spinner is being shown when you edit a title next to the title - Verify that the loading spinner is being shown when you edit a tag next to the tags section - Verify that the loading spinner is being shown when you edit severity next to the severity selectable - Verify that the status and "Sync alerts" is disabled when changing the status - Verify that the status and "Sync alerts" is disabled when changing the "Sync alerts" - Verify that the "edit pencil" is changed to a loading spinner when changing assignees - Verify you can update a comment - Verify you can update the fields of the case ### Checklist - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios --------- Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Summary
This PR converts the remaining cases' hooks to React Query. It also adds the
QueryProvider
to theCasesProvider
to be able to use the hooks when attaching data to a case from outside cases like ML.Fixes: #134663
Testing
Checklist