Defining attributes of web components

[Lorenzo-Pappalardo]

Hi everyone 🙂

I could not find a part in the documentation which talks about passing attributes to the web components registered in the Luigi config, which makes me believe that it is not possible.
Attributes represent a way to easily pass external data to a web component so I find it very strange that this basic behaviour is not supported.

Am I missing something?

I have also analysed the code concerning the creation of a web component node in the DOM and I see that Luigi sets only one attribute for its purposes. However there is no possibility to add more of them.

Supporting this behaviour requires little modifications, in fact I have found a solution by changing the signature of the method responsible for the creation of the node.

Is there a better approach or will there be?

[ndricimrr]

Hi @Lorenzo-Pappalardo ,

Thanks for the question.
The idea is to set a common standard for microfrontend based application creation without reinventing the wheel over and over.
In your case, it is already possible to pass external data to the web component. One standard way of doing that would be through the context passing mechanism which is designed for that need.

In your Luigi config you can have:

   {
        pathSegment: 'sample',
        webcomponent: true,
        context: {
          externalData: 'Some external data',
          count: 100
        },
        viewUrl: '/myWebComponent.js',
   }

Then in myWebComponent.js you can retrieve the data through the context easily using our LuigiElement lifecycle methods:

import { LuigiElement } from "./luigi-element.js"; //comes from @luigi-project/client/luigi-element.js
export default class extends LuigiElement {
  render(ctx) {
    return `<div>Hello ${ctx.externalData}</div>`;
  }
  onContextUpdate(ctx) {
    console.log('context update', ctx);
  }

  afterInit(ctx) {
    console.log('Context count:', ctx.count)
  }
}

Another way of creating webcomponent-based microfrontends would be to use luigi-container. Even though we are still working on it, and adding new features, you can have a look at the example test-app here.
Similarly you can pass context data to your web component based microfrontend like this:

<luigi-container 
        viewURL="https://www.example-microfronted.com" 
        webcomponent="true" 
        label="my label"
        context='{"externalData": "Some external data"}'>
</luigi-container>

Since it can be embedded on any part of your applications DOM, it allows for more flexibility, which might be what you are looking for. Here are some examples to play around with:

const container = document.querySelector('luigi-container')
container.updateContext({ myNewContext: 'some new context data' });
container.sendCustomMessage('My Custom Message to be picked up inside my Web Component');

Let us know if you have further questions

[Lorenzo-Pappalardo]

Hi @ndricimrr,
thanks for the quick response.

I understand that Luigi already has a way to pass data using context, however that ties the web component implementation to the Luigi-specific logic. That by itself is not necessarily a problem as long as the web component is intended for use just in Luigi.

But I would like to have a web component that works also outside of it, so having the possibility to pass data to the web component using the standard approach (via attributes) is important to me. Also because I want to avoid having the Luigi client dependency in each web component.

I think that supporting this use case would not require too many changes in the Luigi logic and would only be a new option available for developers.

I will prepare a small PR as proof-of-concept with the changes needed, in my opinion, to enable this behaviour.
Meanwhile I managed to create a wrapper web component which uses the Luigi context to get data and then is able to pass it to the child web component via attributes.

[Lorenzo-Pappalardo]

Regarding the mentioned wrapper, here is the code:

export default class HelloWorldWC extends HTMLElement {
  set context(ctx) {
    if (ctx.tagName) {
      const element = document.createElement(ctx.tagName);

      for (const key in ctx.attributes) {
        if (Object.hasOwn(ctx.attributes, key)) {
          element.setAttribute(key, ctx.attributes[key]);
        }
      }

      this.appendChild(element);
    }
  }
}

And then in the Luigi configuration you can set:

{
    pathSegment: 'wrapped-hello-world',
    label: 'Wrapped Hello World',
    viewUrl: '/assets/wcWrapper.js', // this is the path to the code of the wrapper
    loadingIndicator: { hideAutomatically: true },
    webcomponent: true,
    context: {
        tagName: 'hello-world', // the tag defined for the web component that needs to be wrapped and passed attributes to
        attributes: { 'example_key': 'example_value' },
    },
},

[hardl]

Hi @Lorenzo-Pappalardo,

thanks for starting this interesting discussion.
After thinking a lot about advantages and possible implications, I would rather not introduce this feature.

I know you mentioned that you have this use case, but I think it is not very common to have a micro frontend/standard reusable component hybrid.
Although both using web component standard, they are IMHO usually very different. It already starts with the way they are consumable, a luigi micro frontend is meant to be hosted on a web server, having an own application lifecycle. Standard web components are usually distributed as a packaged library.
Also luigi doesn't support only web components but also iframe integration (and maybe other ways in the future), and we want to have both ways as similar as possible.

As there is a possibility to achieve what you need using a wrapper web component, I'd say there is no need to have that part of luigi core. IMHO this has even the advantage to keep your generic web component free from luigi-related code, if you may need some luigi client features in the future and just have that in the wrapper.

But maybe I'm missing something, so feel free to disagree ;)

[Lorenzo-Pappalardo]

Hi Philipp,
thanks for the reply.

I think a framework has the aim to simplify development and provide a widely adopted solution to common use cases (like a design pattern).
It is also made of conventions that are somehow "enforced" on the developers, to create a streamlined DX.

If you agree to the previous sentences, then you will find that having the developers create a custom web component wrapper to be able to pass some data to a web component is not very ideal.
Especially if you think that it is the default way according to the Javascript APIs.

Like I said before, enabling this behaviour would only require including a new convention, just like what you did with the "tagName" property. I have opened #3435 to provide my solution for this, if you decide to embrace it.

Let me know 🙃

[hardl]

Hi @Lorenzo-Pappalardo,

I absolutely agree with your general statement, but still don't come to the conclusion that this particular topic is a common use-case.
Maybe this will change, and if we see a high demand, we will definitely consider to add it.
On the other hand I absolutely understand that you are not very happy with creating boiler-plate wrapper-webcomponents if they don't do anything but mapping key-values from one format to another. Therefore we have introduced a new feature that might be helpful in your scenario (and maybe also in others). Since v2.7.0 you can use the webcomponentCreationInterceptor to customize the web component element before it gets added to the DOM, similar to the iframeCreationInterceptor.
With that, you can introduce your own convention exactly as you want, and maybe even add more in the future.

The following example interceptor should work exactly according to your proposal in the PR:

                webcomponentCreationInterceptor: (customElement, navigationNode) => {
                    if( navigationNode?.webcomponent?.tagAttributes) {
                        Object.keys(navigationNode.webcomponent.tagAttributes).forEach(attr => {
                            customElement.setAttribute(attr, navigationNode.webcomponent.tagAttributes[attr]);
                        });
                    }
                }

So you can define a node like that:

{
    pathSegment: 'mfe',
    label: 'MFE',
    viewUrl: './mfe.js',
    webcomponent: {
        tagAttributes: {
            foo: 'bar'
        }
    }
}

Hope that this solution works for you.

Best,
Philipp

[Lorenzo-Pappalardo]

Hi @hardl,
I would like to thank you for taking my request in consideration, I appreciate the exchange of ideas.
I find the solution you provided a good compromise to get the expected results, also having the code written here could be useful to other people.
Again, thank you.