[WIP] Ability to package top bar as web component

[PVince81]

Description

Make Top-Bar.vue compilable as Web Component.
Phoenix core now renders all apps fullscreen, no more top bar.
The apps must include the top bar explicitly, the files app does so here.

Related Issue

• Resend of [POC] Top Bar as web component with separate app selection menu and app internal sidebar #2620

Motivation and Context

Ability for any separate SPA to include the Phoenix top bar and its menus for seamless navigation between apps.
The top bar is also included in OC 10 in this PR: owncloud/core#36529

How Has This Been Tested?

• test environment:
• test case 1:
• test case 2:
• ...

Screenshots (if appropriate):

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Technical debt
• Tests

Checklist:

• Code changes
• Unit tests added
• Acceptance tests added
• Documentation ticket raised:

Open tasks:

• properly pass URLs

• webpack CORS thing

• webpack target: export system.css into dist folder for dynamic inclusion

• webpack target: export top-bar and other web components: node_modules/.bin/vue build --target wc --name phoenix-top-bar src/components/Top-Bar.vue && cp dist/phoenix-top-bar.js ~/work/workspace/owncloud/core/js/phoenix-top-bar.js

• l10n web component: load translations.json directly in Top-Bar.vue

• l10n navigation.json

• fix notifications

• buggy menu toggling

• file size issues in web component

• files app missing scrollbars, probably missing scroll container (now that Phoenix renders the app full screen)

• maybe for the first version, leave the files app alone ?

• todo for later: decouple files app completely from Phoenix core...

• raise: bundle size reduction ideas:

  • make ODS target without automatic registration of components (lazy load)
  • use that "lazy ODS" bundle so it will only contain the needed stuff for the web components

[PVince81]

• issue with "enableAvatars" requiring config object => we should stop using this.$root...
• issue with "applicationsList" requiring config object

[PVince81]

Seems this is getting more tricky now: we need to load the config.json but also let apps register their icons, so we actually need to also load app extension points.

Basically refactor the config and app bits of phoenix.js into utility functions so we can use them in Top-Bar.vue when included as web components.

[PVince81]

I managed to separate and slightly clean up the initialization code of Phoenix to make it reusable in the web component.

However so far the web component doesn't properly boot and debugging minified code is no fun.

[PVince81]

Further attempts, but the drop down of apps menu and user menu are still stuck open.
I thought that maybe UIKit is not able to hook itself up correctly to the DOM inside the web component, considering that there is no html nor body tag...

Including UIKit in the web component entry point didn't help with that.

[PVince81]

Next up would be to try to add debug statements in ODS to see if the UIKit code actually runs, but there is no initialization code as it's all "magic" and likely happens at the time the module is imported. This will be hard to debug.

[PVince81]

rebased

[PVince81]

pfff, I don't understand.

I made every precaution to not import the vue router in the TopBarWebComponent and yet vue insists on calling it. Also I found the vue-router module in the build, as if it just bundled every possible thing instead of just the needed stuff.

[PVince81]

oh, seems the router is likely coming in from ODS:

± % npm ls vue-router
owncloud_phoenix@0.5.0 /home/vincent/Private/Work/workspace/phoenix
├─┬ owncloud-design-system@1.0.4
│ └── vue-router@3.1.5  deduped
└── vue-router@3.1.5 

[PVince81]

UIkit cannot work fully in a Shadow DOM because it's using MutationObserver to react to DOM changes and change behavior like setting "uk-grid" on grids or adding logic for "uk-drop": https://github.com/uikit/uikit/blob/d53e54462d2cfc8c1904446e3508343fb55658e7/src/js/api/boot.js#L20

But the global MutationObserver is not observing DOM changes inside the shadow DOM: https://stackoverflow.com/q/46995421

It would require patching UIKit to use a more complex logic to find out about all shadow DOM entries that are added dynamically and then observe those as well, like it's done for example here: https://github.com/medialize/ally.js/pull/114/files

Somehow it also feels wrong to go this way. Here UIKit is launched inside the Web Component, so I'd expect it to be able to find out about the shadow root and observe only that one.
But apparently the document element is still refering to the main document, not the shadow DOM one.

[PVince81]

adding a "uk-grid" attribute outside the shadow DOM in the OC 10 page markup works, UIKit is initializing it there.
this means that UIKit is escaping the Web Component and operating on the parent elements. not good :-/

[PVince81]

abandoned as it's way more complex than anticipated