Hi guys,
we noticed that the route /configuration/micro-lc-base.js returns correctly the javascript file, but with the wrong content-type:

$ curl localhost:3000/v1/microlc/configuration/micro-lc-base.js -v
*   Trying 127.0.0.1:3000...
* Connected to localhost (127.0.0.1) port 3000 (#0)
> GET /v1/microlc/configuration/micro-lc-base.js HTTP/1.1
> Host: localhost:3000
> User-Agent: curl/7.84.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< content-type: text/plain; charset=utf-8
< content-length: 135
< Date: Tue, 22 Nov 2022 10:58:19 GMT
< Connection: keep-alive
< Keep-Alive: timeout=5
<
...
...
...

As you can see, the content-type is set to text/plain instead of application/javascript.
For this reason, micro-lc doesn't work with some api-gateway.

Can you fix it?

Problem

Currently, micro-lc allows to orchestrate micro-frontends coming from different sources, but since these micro-frontens can vary a lot in UI design, there is a high risk to obtain a overall result which lacks in visual consistency (expecially when the injected plugins offer low to zero support for UI customization).

Proposal

A solution for the issue could be to offer the possibility of injecting a custom stylesheet for the plugins, either at general level (e.g. in the theming section of the config) or inside the configuration of the specific plugin. The former solution could be better for consistency, since the same style is defined only once, but the latter could allow a higher level of precision and avoid to mix styles that are intended to be effective only on a specific micro-fe.

The stylesheet could be injected either by typing directly the CSS code inside the configuration (see example below) or by contacting a specific url passed in the configuration. The first solution is maybe simpler, but could lead to messy configuration if the number of CSS rules to be applied is high.

// example of a configuration
{
  "theming": {
    "header": {
      "pageTitle": "Test",
      "favicon": "https://www.test.it/favicon"
    },
    "logo": {
        ....
    },
    "customCSS": {
        "button.my-button": {
             "background-color": "red",
             "color": "FFFFFF",
             ...
        }
    }

Eventually, micro-lc could then apply specific prefixes to the provided selectors to increment the specificity of the rules:

// example of the result CSS rule
#micro-lc-container button.my-button {
     background-color: red;
     color: "FFFFFF";
     ...
}

It would be great to have an option in the configuration to hide the navigation menù in order to have a much clearer solution using the routing to load plugins and don't force the user interface to implement the menù

I have a page configured by means of the element composer. The configuration is available as attachment in this issue (as *.zip because github doesn't allow the upload of json).
config.json.zip

The page is rendered correctly but there's a problem when the user clicks on "Aggiungi filtro" (add filter), or whenever the user opens the lateral drawer. In that case, for some reason the entire page is moved upwards (see the attached gif: the header is no longer visible after the lateral drawer has been opened). The page stays like that even when the drawer is closed and even if the user navigates to a different section of the website. The only way to get rid of the shift towards the top of the screen is to refresh the page.

Browser: Chrome 103.0.5060.134(arm64)
OS: Mac OS Monterey 12.3.1
Micro-lc version: 0.6.2 (we tried 0.8.0 as well)
Micro-lc element composer version: 0.4.1 (we tried 0.6.0 as well)

I'm using micro-lc with docker-compose in a local environment and I'm also rewriting the index.html file.
I have a simple configuration with only a route /home, which is also the defaultUrl. The route integrationMode is of type compose.

When I open it, it works correctly and it loads the configured page. I would expect the same behaviour if I went to /home/:something but it shows a 404 page.
If I add <base href="/" target="_blank"/> to my index.html and I go to /home/:something, it works as expected and shows the configured page.

I'm using micro-lc version 2.0.9

This is my index.html:

<!DOCTYPE html>
<html lang="en">
<head>
  <base href="/" target="_blank"/>
  <title>micro-lc</title>
  <link rel="icon" href="https://avatars.githubusercontent.com/u/92730708?s=200&v=4" />

  <script type="module" src="https://cdn.jsdelivr.net/npm/@micro-lc/orchestrator@latest/dist/micro-lc.production.js"></script>

  <style>
    html, body {
      position: relative;
      width: 100%;
      height: 100%;
      margin: 0;
    }
  </style>

</head>
<body>
  <micro-lc config-src="./config.json"></micro-lc>
</body>
</html>

when microlc adds app_dataenrty to the url, like "https://xxxxxxx/app_dataentry/bo-prescriptions-drugs?pageNumber=1&pageSize=25&characteristic=0" userinfo is done toward "https://xxxxxxx/app_dataentry/v2/ums/userinfo" so it does not return the actual info, hence the FE will not show the information at the top right corner

Micro-lc should be able to fire onload event only when first rendered application is ready.

I have a heavy bundle and micro-lc doesn't wait for it, so the loading page stops before the bundle is loaded and doesn't show anything but the notification center for a while.

Feature Description

Pipeline steps to publish on NPM and Mia CDN should be separated. Moreover, the batch size for Mia CDN should be lowered.

When creating a configuration that defines some routes, it happens that micro-lc router matches also routes that are not explicitly written, but begin with the same string as an existing route.

Example:

config.json:

{
    "version": 2,
    "applications": {
        "customers": {
            "config": "/customers.json",
            "integrationMode": "compose",
            "route": "/customers"
        }
    }
}

The only provided route is /customers, but the router matches also /customersfoo as /customers

Expected behavior

• Router shouldn't match /customersfoo as /customers

Also take into account the case of query params, path params and anchors.

Hi guys,
with the following issue I would like to introduce a proposal to unbundle the micro-fe orchestration logic from the provided UI. The purpose of the proposal is to the decouple them and offer to our users the ability to build a custom UI around the orchestrator.

How we can divide it?

In the following picture I selected with an orange rectangle the part that should be in the UI package, while I selected with a green rectangle the part that should be in the orchestrator package.

How to re-organize it?

In order to encourage the creation of other UIs for micro-lc, I suggest to move the current UI part into a new repository. It can be seen as a net detachment, but I think that can be useful as base project to start your own new UI around micro-lc, to facilitate potential new users.

Technical approach

To follow the micro-lc's framework-agnostic principle, I suggest to keep a framework-agnostic approach even in this solution.
The UI around it can be done with every framework or even vanilla (for example, we will keep our UI made with React): to make it possible, micro-lc must be available as web-component.
The web-component, that is framework-agnostic by design, will act as always: it will call /api/v1/microlc/authentication and /api/v1/microlc/configuration and will manage the micro-frontend loading according to the defined pluginRoute.

Distribution methods

To facilitate the integration in other UIs, I suggest to make the micro-lc web-component available as npm package.
The current Docker Image will still be available, for who wants to use it as an application shell.
Also, a new Docker Image will be available for the default UI that we provide, to give the same deployment approach that we already provide.

Breaking changes

All this kind of work involve in a lot of breaking changes.
I tried to make a rough estimate, and here follows the results:

• The micro-lc core configuration, exposed through /api/v1/microlc/configuration, will not contain anything about theming, analytics and so on. It will contain only the plugins' configuration.
• The current plugin configuration in the core will loose all the UI-related information, as label, icon and order because it will not manage its display anymore.
• The UI configuration will be exposed with the /api/v1/microlc/configuration/{configurationName} API, and will include the informations about theming, analytics... previously excluded.
• In order to correctly associate a plugin with its labels, icons and behavior, will be used the plugin id.

An example of a new core configuration can be:

{
  "plugins": [
    {
      "id": "plugin-1",
      "aclExpression": "groups.admin || groups.superadmin",
      "integrationMode": "qiankun",
      "pluginRoute": "/myAwesomePlugin",
      "pluginUrl": "https://plugin-url.com",
      "props": {}
    },
    {
      "id": "plugin-2",
      "integrationMode": "href",
      "externalLink": {
        "url": "https://external-site.com",
        "sameWindow": false
      }
    }
  ]
}

While an example of configuration for the UI can be:

{
  "theming": {
    "header": {
      "pageTitle": "Mia-Platform",
      "favicon": "https://favicon-url.com"
    },
    "logo": {
      "url_light_image": "https://logo-url.com/light",
      "url_dark_image": "https://logo-url.com/dark",
      "alt": "My awesome logo"
    },
    "variables": {
      "primaryColor": "red"
    },
    "menuLocation": "topBar"
  },
  "analytics": {
    "privacyLink": "https://policies.google.com/",
    "disclaimer": "We use analytics cookies for...",
    "gtmId": "GTM-XXXXXX"
  },
  "plugins": {
      "plugin-1": {
          "label": "Plugin number 1",
          "icon": "fas fa-rocket",
          "order": 0,
      },
      "plugin-2": {
          "label": "Plugin number 2",
          "icon": "fas fa-TAG",
          "order": 1,
      }
  }
}

BE CAREFUL: the above UI settings will be used by the UI that we already provide. If a user wants to create his UI from scratch, he can create his own configuration

Communication interfaces between UI and micro-lc

In order to communicate to the UI the plugins that has been loaded with micro-lc, we can use two approach:

1. Make them available in an freezed object stored inside the window;
2. Include them in the detail part of a Custom Event.

I prefer the second approach, as it results much cleaner IMO.

Conclusions

This refactoring will make micro-lc more general purpose, and will allow our teams to customize the UI around each customer needs.

Let me know what do you think about it!

We must provide support for SEO.
We've already made an image of prerender that can be used as sidecar: now we should configure the NGINX instance of micro-lc in order to redirect the crawler traffic to that sidecar.

It should be something similar to this

Description
The href attribute of the <base> tag inside <qiankun-head> should contain only the route configured in the config file but it contains the complete url (excluded the base).

I'm serving configurations using version 2.0.8.

Reproduction
Configure a micro-frontend on a route (ex. /my-microfronted/) and open the page adding one or more subdirectory to the url (ex. localhost/my-microfrontend/user/value). Open the inspector and inside the <qiankun-head> tag there is the <base> tag with an href attribute. The href value will be something like /my-microfrontend/user/value instead of just /my-microfronted/

At the moment, in the page header, upon clicking on the user avatar, a menu with only one CTA is shown, and the action is "disconnect".

It'd be useful to be able to configure other CTAs, like a simple link to the profile section.

The microlc side menu last last plugin on many when all sections of a long list are expanded.

I have try to find integration of micro-lc with Vue projects but I don't found any.

So I have created two hello world VUE3 TYPESCRIPT VITE projects and make the base configuration with micro-lc.
https://github.com/clabnet/microlc-vue

The actual result is the start of micro-lc page with a 400 error, and 500 errors when activating MFE1 or MFE2.

Do you like please support me to configure correctly for run the two simple projects as "parcel" mode ?

Thank you very mutch.

A suggestion.
Because micro-lc supports also communication between web component thanks to Element Composer I suggest to add this information in both README.md of micro-lc and introduction on official documentation https://docs.mia-platform.eu/docs/business_suite/microlc/overview