[Security Solution] [Flyout] drive flyout state with url or memory + support back button navigation from timelines#169661
Conversation
a962059 to
b652e59
Compare
6c417ba to
4ca42f5
Compare
x-pack/plugins/security_solution/public/common/hooks/timeline/use_init_timeline_url_param.ts
Outdated
Show resolved
Hide resolved
|
I see some differences in behavior between flyout and timeline. After closing the flyout, I can click on the browser back button and the flyout correctly reopens. Screen.Recording.2023-11-14.at.2.14.56.PM.movBut doing the same with timeline doesn't work. Timeline does not reopen on the screen. Screen.Recording.2023-11-14.at.2.16.53.PM.mov |
|
There is also a weird behavior with timeline, where using the browser back button then going forward again reopens the timeline but looses the previously selected timetange, query and result (though the Query tab title has the correct result count) Screen.Recording.2023-11-14.at.2.20.44.PM.mov |
|
This was probably not the original focus of this work, but I find it not user friendly that when I click on the bowser back button after having navigated through tabs within the flyout, we don't go back through these same tabs. It works for the very top level ones (
Screen.Recording.2023-11-14.at.2.29.56.PM.mov |
|
The Screen.Recording.2023-11-14.at.2.38.30.PM.mov |
|
Opening a preview panel doesn't work anymore Screen.Recording.2023-11-14.at.2.49.25.PM.mov |
341c624 to
d87b687
Compare
|
dccc38a to
b4a223b
Compare
should work now |
d81820f to
e072101
Compare
4871114 to
c6a8fdb
Compare
PhilippeOberti
left a comment
There was a problem hiding this comment.
This is super close, left a few comments.
One thing @christineweng mentioned is that Kibana has a util package for url and memory management, @lgestc did you look into it by any chance? (I haven't yet)
src/plugins/kibana_utils/docs/state_containers/README.md
src/plugins/kibana_utils/docs/state_sync/README.md
packages/kbn-expandable-flyout/src/context/memory_state_provider.tsx
Outdated
Show resolved
Hide resolved
packages/kbn-expandable-flyout/src/context/memory_state_provider.tsx
Outdated
Show resolved
Hide resolved
packages/kbn-expandable-flyout/src/context/url_state_provider.tsx
Outdated
Show resolved
Hide resolved
packages/kbn-expandable-flyout/src/context/url_state_provider.tsx
Outdated
Show resolved
Hide resolved
x-pack/plugins/security_solution/public/flyout/document_details/left/tabs/visualize_tab.tsx
Outdated
Show resolved
Hide resolved
x-pack/plugins/security_solution/public/timelines/components/flyout/header/active_timelines.tsx
Outdated
Show resolved
Hide resolved
why not, I will take a look. |
@lgestc I debated adding the comment. I feel like the PR is so close and will be such a nice feature to have in |
packages/kbn-url-state/index.ts
Outdated
There was a problem hiding this comment.
@lgestc , love the simplicity of the API.
I understand that you are delaying updates to the next microtask with setTimeout but I don't 100% understand, how does it batches the state updates.
Also, I think something like debounce can provide a clearer api for batching very quick successive updates,
There was a problem hiding this comment.
so the changes are first appended to some global object, and then flushed to the url, but we are going to drop this custom thing in favor of already made url storage solution linked somewhere here
There was a problem hiding this comment.
So I just reviewed kbn-url-state and so far it looks great. I have added couple of more questions/comments.
But I think there is something like it already exists. Sorry to say this so late in the party as I know you have put a lot of effort in this.
While working on Discover work, I observed that discover is already using url sync state management solution which is as shown below:
I am not sure if you are already aware of this. But do you think it makes sense to add your improvements in this existing plugin?
packages/kbn-url-state/index.test.ts
Outdated
There was a problem hiding this comment.
Would be great to know the reason for removing these tests because this can surely use many more tests.
packages/kbn-url-state/index.ts
Outdated
There was a problem hiding this comment.
Since, you are already implementing this, I would like to bring one more usecase for this to your attention.
In the Filter group controls on the Alerts Page, I use a custom hook to sync the url with the state as shown below.
One requirement in this was to pause/resume sync on demand. For example, when user is editing the controls, we do not want to sync the state but otherwise, we want to.
Something to think about when finally implementing this.
There was a problem hiding this comment.
I feel like this is out of scope for this PR. Would you be ok if we take a look at this later? Especially because we might actually drop this package entirely in favor for another already existing one...
There was a problem hiding this comment.
100%, this was a use case for synching url changes that I wanted to bring to attention. No hurry on this.
and I agree on the point of using existing one. Thanks.
195803a to
4edce9f
Compare
So, adding this to the flyout package results in the following error. I am yet to figure out what is the problem here. |
There was a problem hiding this comment.
silly nit, but can we just call this closeFlyout? I get the openPanels one since you can pass a configuration of panels, but this one just closes everything taking no args
There was a problem hiding this comment.
I think keeping closePanels is ok here, as it was written like this originally, to make all the variable names consistent within the file. You have openPanels, openRightPanel, openLeftPanel, openPreviewPanel, closeRightPanel, closeLeftPanel, closePreviewPanel, and closePanels 😄
There was a problem hiding this comment.
the developer facing API for the package showsopenFlyout and closeFlyout, which is what really matters.
I just have OCD wanted to have all the variable within that file be consistent...
PhilippeOberti
left a comment
There was a problem hiding this comment.
This is really awesome, thank you for going through and implementing this! The code looks perfect to me 😃
I tested a lot of scenarios and couldn't find any issues!
There was a problem hiding this comment.
if you make another change to the PR and have to push some code, let's remove this @returns
<3 |
💚 Build Succeeded
Metrics [docs]Module Count
Public APIs missing comments
Async chunks
Public APIs missing exports
Unknown metric groupsAPI count
ESLint disabled line counts
Total ESLint disabled count
History
To update your PR or re-run it, just comment with: |
rylnd
left a comment
There was a problem hiding this comment.
Reviewed on behalf of detection-engine and entity-analytics. Code changes there look pretty innocuous, all the interesting stuff is on the other teams 😉 .
I had one question about a comment's utility, but generally this is fine from our end. LGTM.
| openLeftPanel: () => window.alert('openLeftPanel called'), | ||
| panels: {}, | ||
| } as unknown as ExpandableFlyoutContext; | ||
| } as unknown as ExpandableFlyoutContextValue; |
| ); | ||
| }; | ||
|
|
||
| // NOTE: provider below accepts "storage" prop, please take a look into component's JSDoc. |
There was a problem hiding this comment.
I'm not sure this comment is doing much. Are you intending to indicate that they may change the component's behavior by changing this hardcoded prop? Why is that important here?

Summary
This is a PoC for flyout state (left, right, preview panels) stored entirely in the url without separate syncing mechanism. It is also possible to opt in for in-memory storage.
This vs current solution:
https://github.com/elastic/security-team/issues/8135