-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
[SecuritySolution] Retrieve onboarding steps #181442
Conversation
@@ -469,23 +476,17 @@ const EventDetailsComponent: React.FC<Props> = ({ | |||
); | |||
|
|||
return ( | |||
<GuidedOnboardingTourStep |
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 should only wrap only the target tab with the GuidedOnboardingTourStep
to avoid adding extra attributes to other tabs in their DOM elements and cause the tour anchor locate incorrectly.
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.
const isAddToNewCaseFlyoutOpen = cases.hooks.useIsAddToNewCaseFlyoutOpen(); | ||
const isAddToExistingCaseModalOpen = cases.hooks.useAddToExistingCaseModalOpen(); | ||
|
||
const hiddenWhenCasesModalFlyoutExpanded = useMemo( |
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.
@@ -190,6 +192,8 @@ export class CasesUiPlugin | |||
hooks: { | |||
useCasesAddToNewCaseFlyout, | |||
useCasesAddToExistingCaseModal, | |||
useIsAddToNewCaseFlyoutOpen, |
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.
Please find our use cases here
</CellTooltipWrapper> | ||
), | ||
render: (value: string, caseData: RelatedCase) => { | ||
const index = data.findIndex((d) => d.id === caseData.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.
In the existing guided onboarding tour's logic, it only shows the tour step if index equals to 0
const { activeStep, isTourShown } = useTourContext(); | ||
const isGuidedOnboardingTourShown = | ||
isTourShown(SecurityStepId.alertsCases) && activeStep === AlertsCasesTourSteps.viewCase; | ||
const expanded = |
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.
Expand the insight section automatically after the test case created, so the relevant cases can be fetched.
); | ||
|
||
const renderTabs = tabs.map((tab, index) => | ||
isAlert && tab.id === 'overview' ? ( |
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.
Same reason as this one: https://github.com/elastic/kibana/pull/181442/files#r1586866840
const onAddExceptionTypeClick = useCallback( | ||
(exceptionListType?: ExceptionListTypeEnum): void => { | ||
setExceptionFlyoutType(exceptionListType ?? null); | ||
setAllTourStepsHidden(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.
buildkite test this |
/ci |
buildkite test this |
buildkite test this |
Hi @PhilippeOberti, I've been checking the re-renders you mentioned. It's an interesting point, the reason we see the table cells highlighted is not the This hook is the only code that gets re-executed, it needs to check if the flyout "expanded" value has changed, there's no way around that if we want to have a tour anchor inside a table cells. The good news is that the only component that updates is the tour_updates_only_anchor.mov |
/ci |
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 seems like a lot of changes to many different cross cutting concerns to fix something that I think could/should be done in the onboarding code, but the re-renders are no longer as bad as they were, 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.
I understand the reasoning behind adding the casesContextState$
in the cases context provider value but I think it breaks the encapsulation between the internal state and the value of the provider. Instead of exposing the state this way, what do you think about passing a callback to the provider? Example:
export const CasesProvider: FC<
PropsWithChildren<{
value: CasesContextProps;
queryClient?: QueryClient;
}>
> = ({
children,
value: {
externalReferenceAttachmentTypeRegistry,
persistableStateAttachmentTypeRegistry,
owner,
permissions,
basePath = DEFAULT_BASE_PATH,
features = {},
releasePhase = 'ga',
getFilesClient,
},
queryClient = casesQueryClient,
onToggleFlyout,
}) => {
const [state, dispatch] = useReducer(casesContextReducer, getInitialCasesContextState());
const onDispatch = (args) => {
if (args.type === CasesContextStoreActionsList.OPEN_CREATE_CASE_FLYOUT ) {
onToggleFlyout({isFlyoutOpen: true})
}
onDispatch(args)
};
// rest of code
};
Hey @cnasikas yes, using the observable inside the context is not a conventional approach, I understand why you prefer the
This is a very specific implementation for what we need right now, it'd need to be extracted to a new "side-effects" module to make it extensible, and the As an alternative, I have a third proposal: This approach is explained in the react documentation docs. I think this is cleaner than the other 2 options, more reusable, does not mess up with the current context, and is very easy to use for us. |
@semd I really like the new proposal. I knew there was something better but I could not figure it out. Thanks! Does the order of context providers matter? Also should we add the new context provider here |
Great! Yes, Angela and I have been discussing this code for quite a while, and the observable was my idea lol, but none of us were convinced about it. Creating a separate context for the state makes a lot more sense.
Nope. The only thing that matters is that the provider wraps the consumer at some level.
Exactly, since the |
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 your willingness to help and find a new solution! LGMT!
x-pack/plugins/cases/public/components/cases_context/state/use_is_add_to_case_open.test.tsx
Outdated
Show resolved
Hide resolved
x-pack/plugins/cases/public/components/cases_context/state/use_is_add_to_case_open.test.tsx
Outdated
Show resolved
Hide resolved
x-pack/plugins/cases/public/components/cases_context/state/use_is_add_to_case_open.test.tsx
Outdated
Show resolved
Hide resolved
@elasticmachine merge upstream |
@elasticmachine merge upstream |
💚 Build Succeeded
Metrics [docs]Module Count
Async chunks
Public APIs missing exports
Page load bundle
History
To update your PR or re-run it, just comment with: |
Summary
Fixes #181190
Relevant PRs: #143598 | #163739
Steps to Verify:
It compatible with the new expandable flyout:
expandable flyout tour
when the guided onboarding tour is not enabled.hidden
when theleft
expandable is opened.Add to new case
flyout orAdd to existing case
modal opened.insight section
andcorrelation tab
should be opened automatically to fetch cases.expandable flyout tour
should be visible again after the guided onboarding tour is finished.Screen.Recording.2024-05-03.at.14.30.03.mov
It compatible with the old flyout:
Screen.Recording.2024-05-01.at.21.19.29.mov
Checklist
Delete any items that are not applicable to this PR.