Allow consumer to register different versions of Auro components

[janabimustafa]

Hello,

I'd like to open a discussion around an enhancement that could significantly improve the development experience and flexibility for projects using Auro Components.

The Challenge

In our current workflow, when creating a new microsite, we often start by integrating the header/footer component. This component typically includes its own set of Auro Components, which may not always be the latest versions. These pre-included components are registered under window.customElements, which leads to a common issue: once a custom element is registered with a given name, it cannot be redefined or updated to a newer version within the same document. Consequently, this limits our ability to use updated versions of Auro Components within our microsites, potentially leading to inconsistency and outdated implementations across different parts of the UI.

Proposed Solution

One potential solution to this challenge is to allow more flexibility in registering Auro Components under custom names, particularly for cases where version discrepancies occur. This approach would involve exposing the Auro Component classes directly, enabling clients (i.e., microsite developers) to register components under unique names within their own scope.

For example, if a microsite requires a more recent version of auro-button than what is provided by the header/footer component, the developer could register this updated version under a custom name, such as window.customElements.define("auro-mymicrosite-button", UpdatedAuroButtonClass). This would allow the microsite to utilize the latest version of the component without conflict with the version included in the header/footer.

Benefits

• Flexibility: Allows developers to incorporate the most up-to-date versions of Auro Components as needed, without being constrained by the versions bundled with shared components like headers/footers.
• Isolation: Reduces the risk of conflicts between different versions of the same component used within various parts of a site.
• Incremental Upgrades: Facilitates a more granular approach to upgrading components, enabling individual sections of a site to adopt new versions independently.

Request for Alternatives and Feedback

While the above proposal outlines one possible route to addressing the versioning challenge with Auro Components, I am keen to explore alternative solutions and hear from the community. Your insights, experiences, and suggestions could be invaluable in shaping a comprehensive approach to this issue.

• Have you encountered similar challenges in your projects?
• Are there other strategies or best practices you've found effective in managing component versions?
• How might we improve this proposal to better serve the needs of the Auro Components user base?

Thank you for considering this proposal. I look forward to a productive discussion and to collaboratively developing a solution that enhances the usability and versatility of Auro Components for all users.

[janabimustafa]

We can register a custom implementation of an auro component by using the exported registerComponent method.

import {registerComponent as registerButtonComponent} from '@aurodesignsystem/auro-button';
registerButtonComponent('auro-nls-button');

[blackfalcon]

There is this issue AlaskaAirlines/AuroDocsSite#176 to create better documentation for this capability.

[blackfalcon]

@janabimustafa I want to keep this open. While we already support a solution you are looking for, I want to work with the header/footer to reduce, if not remove that naming collision.

[blackfalcon]

@janabimustafa in the header/footer package.json I see these dependencies.

  "dependencies": {
    "@alaskaairux/auro-header": "^1.5.5",
    "@aurodesignsystem/auro-hyperlink": "^3.3.7",
    "@aurodesignsystem/auro-icon": "^4.0.2",

What I see in the header/footer repo, only hyperlink and icon are being re-registered under custom names.

import { registerComponent as registerHyperlink } from '@aurodesignsystem/auro-hyperlink';
import { registerComponent as registerIcon } from '@aurodesignsystem/auro-icon';

const registerComponents = () => {
  registerHyperlink('hf-auro-hyperlink');
  registerIcon('hf-auro-icon');
};

export { registerComponents };

Header should be added to this list.

You shared with me the re-named elements in the auro.ts file that includes:

1. button
2. badge
3. hyperlink
4. icon
5. skeleton
6. loader

Are you getting name clashing with button, badge, skeleton, and loader or was this preemptive coding?

[blackfalcon]

Dropping this link here for reference. Shoelace.style has an interesting solution for avoiding registration collision that I want to see of we can apply to Auro.

https://shoelace.style/getting-started/installation#avoiding-auto-registering-imports