Skip to content
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

[serverless][poc] Unified Navigation #153274

Closed

Conversation

clintandrewhall
Copy link
Contributor

@clintandrewhall clintandrewhall commented Mar 19, 2023

Consolidates #152172 into clean commits.

My goal is to have this reviewed and merged into the serverless/poc/main feature branch. I'll also submit for review after CI clears.

Summary

This POC is an application of the principles I've outlined elsewhere, using "unified navigation" as a functional example, where:

  • core changes are established as functional changes, rather than "serverless" changes;
    • e.g. chromeStyle, setSolutionNavigation
  • relevant plugins expose functional changes as APIs
  • a single serverless plugin provides APIs related to Serverless functional implementations;
  • other serverless-[project space] plugins use core, serverless and other plugins to create their Kibana configuration.

By simply enabling the serverless and serverless-* plugin, we can create a project.

@clintandrewhall clintandrewhall added the WIP Work in progress label Mar 19, 2023
@github-actions
Copy link
Contributor

Documentation preview:

@clintandrewhall clintandrewhall force-pushed the serverless/poc/unified_navigation branch 13 times, most recently from 2f2164c to 33b47b4 Compare March 20, 2023 17:43

return (
<EuiThemeProvider colorMode={colorMode === 'DARK' ? 'LIGHT' : 'DARK'}>
<EuiCollapsibleNav
Copy link
Contributor

@semd semd Mar 21, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In Security we have an ongoing initiative to display a collapsed version of the navigation, showing only icons. I am not sure if it is going to happen anytime soon, but that would be hard to implement if the core header owns the collapsible.
Would it make sense to delegate the collapsibility to the Project navigations? another option is to get a rendering element from Projects, instead of a children node, and pass the isOpen by prop.

Copy link
Contributor Author

@clintandrewhall clintandrewhall Mar 21, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

a collapsed version of the navigation, showing only icons

This is @MichaelMarcialis and @ryankeairns vision for the navigation, so that would fall to Shared UX. We should try to surface these there, rather than force Security and other teams to implement themselves.

@tsullivan has been starting on a PoC for precisely this feature.

Copy link
Contributor

@semd semd Mar 21, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good! it looks like this is aligned with Security vision (cc @dimadavid @bfishel).

Sounds great to have a Shared UX nav component available, I hope we can all agree on the design and reuse it. But we shouldn't also force Solutions to use it.
Anyhow, in this navigation architecture, I understand that Solutions (in their serverless plugin) will be responsible for importing this new SharedUX component (or any other) and rendering it via setServerlessNavigation, so it will still need to manage collapsibility, isn't it?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds great to have a Shared UX nav component available, I hope we can all agree on the design and reuse it. But we shouldn't also force Solutions to use it.

Agreed.

Anyhow, in this navigation architecture, I understand that Solutions (in their serverless plugin) will be responsible for importing this new SharedUX component (or any other) and rendering it via setServerlessNavigation, so it will still need to manage collapsibility, isn't it?

The collapsibility will already need to be there, because the items surrounding the solution "section" of the navigation will support the collapse behavior. There are still items to sort out, but yeah: setServerlessNavigation currently appears to be the entire navigation, but as we flesh out other requirements, it will likely be one section, (e.g. Recent Items)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see, then this Solution nav "section" will also need to know if the nav is open or closed somehow, maybe we can do that with CSS only, not sure. Can't wait to see the Shared UX approach for the collapsed version.

Composing the nav with different sections sounds like a good pattern. It will probably limit the ability of Solutions to have their own navigation design (without becoming a "Franken navigation" 😂, just joking), but okay, we have to find a balance, let's see how it evolves 👍

Copy link
Member

@tsullivan tsullivan Mar 23, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@semd I have this draft PR based on elastic:serverless/poc/unified_navigation which adds a new package called @kbn/shared-ux-chrome-navigation to implement a shared nav component: #153508

In my draft, the collapsibility is being handled by the ChromeService - there is a new internal observable to manage the open/closed state. Solutions can read the value of the observable just like any other observable, if they want to.

I'm eager to know what you think!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@tsullivan Yeah looks good 👍 It is a smart solution. We'll be able to use the same observable from the Security navigation.
We lose the local storage functionality though, we have this feature in the internal Security nav for ESS. Would it make sense to implement it in the core internal nav? It has setNavIsOpen available.

</EuiHeaderSectionItem>
</EuiHeaderSection>
</EuiHeader>
<Router history={application.history}>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

❤️

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This likely needs to change to core router in prod. @vadimkibana and @lukeelmers , can you weigh in?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not completely sure, would need to play with the code, but it might be already good. As the application.history is the one from "core", so it sort of already is the "core router".

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe the history here is pulling from core's internal application service contract, which means it is the global (unscoped) history instance that's currently only accessible to core.

We'll need to think about what we want to expose here for the project navs in serverless. Since the navs could be anything, it may be hard to avoid leaking the global history. cc @pgayvallet @rudolf

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The project nav isn't / shouldn't be scoped to a given plugin path, so using the global history seems fine to me, especially given its usage will be isolated in Core code / packages

@clintandrewhall clintandrewhall force-pushed the serverless/poc/unified_navigation branch from a7af0ea to a0ccf6b Compare April 20, 2023 13:31
@clintandrewhall clintandrewhall force-pushed the serverless/poc/unified_navigation branch from a0ccf6b to cc1a802 Compare April 21, 2023 01:56
@clintandrewhall clintandrewhall force-pushed the serverless/poc/unified_navigation branch from cc1a802 to 89bd09c Compare April 21, 2023 02:28
@kibana-ci
Copy link
Collaborator

💛 Build succeeded, but was flaky

Failed CI Steps

Test Failures

  • [job] [logs] FTR Configs #15 / security app dls "after all" hook: logout for "user East should only see EAST doc"
  • [job] [logs] FTR Configs #15 / security app dls should add new role myroleEast
  • [job] [logs] FTR Configs #15 / security app dls should add new user userEAST
  • [job] [logs] FTR Configs #15 / security app dls user East should only see EAST doc

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id before after diff
core 417 423 +6
serverless - 10 +10
serverlessObservability - 4 +4
serverlessSearch - 5 +5
serverlessSecurity - 59 +59
total +84

Public APIs missing comments

Total count of every public API that lacks a comment. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats comments for more detailed information.

id before after diff
@kbn/core-chrome-browser 46 47 +1
enterpriseSearch 7 9 +2
securitySolution 76 80 +4
serverless - 9 +9
serverlessObservability - 6 +6
serverlessSearch - 6 +6
serverlessSecurity - 6 +6
total +34

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id before after diff
core 145.5KB 145.5KB +12.0B
enterpriseSearch 2.3MB 2.3MB +144.0B
management 34.0KB 34.0KB +31.0B
observability 1.1MB 1.1MB -900.0B
securitySolution 9.1MB 9.1MB -3.0KB
serverlessSecurity - 7.7KB +7.7KB
total +4.0KB

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id before after diff
core 352.9KB 360.6KB +7.7KB
enterpriseSearch 31.0KB 31.1KB +155.0B
fleet 126.7KB 126.7KB +8.0B
management 9.8KB 10.0KB +164.0B
observability 74.5KB 74.9KB +452.0B
observabilityShared 12.8KB 12.9KB +43.0B
security 61.2KB 61.3KB +137.0B
securitySolution 58.3KB 59.5KB +1.2KB
serverless - 4.0KB +4.0KB
serverlessObservability - 1.7KB +1.7KB
serverlessSearch - 2.4KB +2.4KB
serverlessSecurity - 26.1KB +26.1KB
total +44.1KB
Unknown metric groups

API count

id before after diff
@kbn/core-chrome-browser 120 126 +6
enterpriseSearch 7 9 +2
securitySolution 117 121 +4
serverless - 9 +9
serverlessObservability - 6 +6
serverlessSearch - 6 +6
serverlessSecurity - 6 +6
total +39

async chunk count

id before after diff
serverlessSecurity - 1 +1

ESLint disabled line counts

id before after diff
securitySolution 394 396 +2
serverless - 3 +3
serverlessObservability - 4 +4
serverlessSearch - 4 +4
serverlessSecurity - 4 +4
total +17

miscellaneous assets size

id before after diff
serverlessSecurity - 68.4KB +68.4KB

Total ESLint disabled count

id before after diff
securitySolution 474 476 +2
serverless - 3 +3
serverlessObservability - 4 +4
serverlessSearch - 4 +4
serverlessSecurity - 4 +4
total +17

History

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

clintandrewhall added a commit that referenced this pull request Apr 26, 2023
…155583)

> Derived from #153274

## Summary

This PR extracts configuration settings for enabling/disabling plugins
in Serverless projects based on current requirements.

It seemed prudent to create an independent PR to K.I.S.S, rather than
include in PRs with more ornate changes, (e.g.
#155582)
clintandrewhall added a commit that referenced this pull request Apr 26, 2023
> Derived from #153274 for
production.

## Summary

This PR creates the `serverless` plugin for Kibana Serverless projects.


![image](https://user-images.githubusercontent.com/297604/233892935-b3713575-a2f7-4e82-a9dd-e8c11823683f.png)


It uses the methodology proven out in the proof-of-concept
(#153274) and prepares it for
production:

- Adds chrome style and related API to the `chrome` services.
- Creates the `serverless` plugin.
- Invokes the new chrome style API for all serverless projects.
- Alters `yarn` scripts to support all project types, and switching
between them.
- Creates the new "Project Switcher" component for use in the new chrome
header for Serverless.
- Creates a Storybook config for this and future components.
- Adds API endpoint to trigger project switching and `Watcher` restarts.

<img width="1598" alt="Screenshot 2023-04-26 at 10 44 01 AM"
src="https://user-images.githubusercontent.com/297604/234612654-fdcf38ea-8c48-4066-bc85-507f40c984aa.png">


## Next steps

- [x] Creating a PR for enabling/disabling related plugins for
Serverless. (#155583)
- [ ] Creating product plugin PR based on
#153274.

---------

Co-authored-by: kibanamachine <[email protected]>
clintandrewhall added a commit that referenced this pull request May 1, 2023
> Derived from #153274
> Builds upon #155582

## Summary

This PR creates the Serverless Observability plugin, based on the work
from #153274:

- creates the plugin,
- adds API to hide the solution navigation from Enterprise Search,
- calls that API if the chrome style is `project`.

<img width="1610" alt="Screenshot 2023-04-27 at 5 03 44 PM"
src="https://user-images.githubusercontent.com/297604/234990765-d6770650-41b3-4e94-ad7f-c6a22778d39a.png">

---------

Co-authored-by: kibanamachine <[email protected]>
clintandrewhall added a commit that referenced this pull request May 2, 2023
> Derived from #153274
> Builds upon #155582

## Summary

This PR creates the Serverless Security plugin, based on the work from
#153274:

- creates the plugin,
- adds API to hide the solution navigation from Security,
- calls that API if the chrome style is `project`.

<img width="1688" alt="Screenshot 2023-04-27 at 12 37 46 PM"
src="https://user-images.githubusercontent.com/297604/234979670-425bfb12-8194-4916-8f92-efff7804b577.png">

## Next Steps

- render the left nav from #153274
using an API provided by @elastic/appex-sharedux
  - this low-level API should be coming in the next few days.

---------

Co-authored-by: kibanamachine <[email protected]>
@semd semd closed this Oct 4, 2023
@semd semd deleted the serverless/poc/unified_navigation branch October 4, 2023 09:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
WIP Work in progress
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants