[new-platform] Decouple ui/chrome from angular

[joshdover]

We need to decouple all the functionality that ui/chrome provides via Angular. This includes:

• Any route handling or hacking that Chrome does
• Any configuration that chrome adds to the kibana angular module
• Any services or providers added by chrome to the kibana angular module

In addition, we need to remove the angular bootstrapping code from chrome and into each application plugin. This will enable applications that do not require angular to completely decouple themselves from it once the new platform provides an Application Service for loading apps (#18843).

This issue will be fleshed out further and broken down as I dive into ui/chrome to identify the major pieces that need to be removed and how that will need to be coordinated across the project.

There are also a few non-angular APIs still provided by the legacy chrome that need to moved over to the new platform (#20696). This may or may not be coupled to this effort.

Execution Plan

• Move global Angular config into shared file (Extract angular configuration from ui/chrome #34314)
• Move chrome.nav APIs to Core
  • NavLink APIs
  • SubUrl APIs
• Render chrome UI in Core
• Refactor plugins to use ui/new_platform directly instead of ui/chrome
• Move angular bootstrapping to individual plugins

[elasticmachine]

Pinging @elastic/kibana-platform

[joshdover]

Categories of Angular things in ui/chrome

Here I've done a deep dive into all the things that ui/chrome does. I'm sharing this to help clarify what's going on with others. In a follow up, I'll start to put together a plan of how we tackle this.

I'll try to keep this up to date as I learn more, but you can also follow along here.

Static config

• kbnVersion, buildNum, buildSha, serverName, sessionId, esUrl

Global angular setup/configuration

• $locationProvider
  • Setup html5mode (disabled), this is router related
  • Set hashPrefix
• $httpProvider.interceptors
  • Setting kbn-version header / xsrf token
• $http
  • Capturing the loading count (already integrated with Core)
• $compileProvider
  • Set debugInfoEnabled
• $rootScope
  • Setting up breadcrumbs autoclear (integrated with Core) on route change
  • Setting up help extension autoclear (integrated with Core) on route change
  • Setting up deep watch for navLinks. Only necessary because some apps mutate navLinks directly (which??)
• UrlOverflowService
  • This pushes long urls into sessionStorage and shows warning toasts if the URL is longer than some warning threshold.
• globalNavState Service
  • Currently only used by the security plugin's navControl to hide a tooltip when the sidebar is collapsed. This could easily be replaced by an observable in Core.

UI

• The directives for the header, and chrome itself need to be moved to be powered by Core.
• kbn-append-nav-controls can be removed, it's not being used anymore.
• We will need remove our usage of the ui/registry/chrome_nav_controls registry to decouple from Angular. This is only used a handful of places so this shouldn't be too bad.
• The kbn-chrome directive provides a lot of functionality that needs to be removed or copied to plugins:
  • Updating sub URLs
    • This is just a simple service that handles putting you back in the same place you were in last time you were in a specific app. Should be moved to Core (App service?)
  • Rendering of the global banner list (which is powered by Core)
  • Handles some correction of hash parsing to fix a back button bug
  • This all seems like functionality that could be moved into the "global Angular config" category above. Not sure why it's stuffed into this directive.
  • Doesn't seem like it needs to be part of Core necessarily, could be pushed down to individual apps pretty easily.

Bootstrapping

Entry point flow

• CoreSystem setup: setup core services, setup plugins, setup LegacyService
• LegacyService setup:
  • shim the ui/public modules with their Core equivalents,
  • require ui/chrome,
  • require the plugin's public main file (the file specified in the plugin's spec under uiExports.app.main)
    • The structure of a plugin's main file can vary
      • For a complex Angular-heavy plugin, you'd typically see routes being registered. Each route handler would provide a template that gets injected into the ng-view along with a controller. This entry point would also import any uiExport modules.
      • For a simple Angular plugin without routes or one that uses React and react-router, you'd typically see a call to chrome.setRootTemplate. Optionally, the app could also call chrome.setRootController. Some React apps then poll for when the root template has been inserted into the DOM and then grab a DOM element to use to boot their React app.
  • call chrome.bootstrap with targetDomElement
  • chrome.bootstrap: require uiExports/chromeNavControls, require uiExports/hacks, create global angular module (called "kibana"), call angular.bootstrap(targetDomElement, ['kibana']);
    • chrome.bootstrap source
  • The global angular app renders the kbn-chrome directive which either:
    • Replaces the ng-view with the root template if chrome.setRootTemplate was called; or
    • Does nothing, lets the router take over and render the template based on the URL

chrome.dangerouslyGetActiveInjector

• Once bootstrapping is copied to individual plugins, this can be copied into plugins that need it. Appears to mostly be used by visualizations.

Shimmed APIs

APIs that are powered by Core, but exposed to the legacy platform through ui/chrome need to be removed by refactoring legacy plugins to import them from ui/new_platform.

This is non-critical for getting rid of Angular, but is needed to get rid of this module completely.

[joshdover]

For many of the static values provided via .value('settingName'), we will need a config service in the client-side new platform so that Angular apps that need it can import them from somewhere.

[joshdover]

Most of this has been completed and there's a lot of overlap now with this and the plans in #18843. Closing.