Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Transitioning IX to Use a Directive for a Button Component #1748

Open
2 tasks done
lucasluizss opened this issue Mar 4, 2025 · 2 comments
Open
2 tasks done

Transitioning IX to Use a Directive for a Button Component #1748

lucasluizss opened this issue Mar 4, 2025 · 2 comments
Labels
triage We discuss this topic in our internal weekly type: enhancement New feature or request

Comments

@lucasluizss
Copy link

Prerequisites

  • I have read the Contributing Guidelines.
  • I have not leaked any internal/restricted information like screenshots, videos, code snippets, links etc.

Suggestion / feature request

This proposal outlines the benefits and implementation strategy for transitioning IX from using a button component to a directive-based approach. By leveraging directives, we can enhance reusability, maintainability, and flexibility within the IX framework.

Rationale

Separation of Concerns - Directives allow behavior to be abstracted from the component structure, making it easier to apply across multiple elements without modifying component templates.

  • Reusability - A directive can be attached to any element, reducing the dependency on a specific button component.

  • Maintainability - Centralizing logic within a directive reduces redundancy and simplifies future updates.

  • Improved Customization - Developers can apply the directive to various elements without being constrained by predefined button styling or structure.

Proposed Implementation

Directive Creation

Develop an Angular directive (e.g., ixAction) that encapsulates the existing button’s logic.

Ensure it can be applied to multiple elements (e.g., div, span, a), not just buttons.

Event Handling

The directive will handle click events, keyboard interactions, and other necessary event listeners.

Provide inputs for customization, such as action type, disabled state, and accessibility attributes.

Backward Compatibility

The existing button component will remain available during the transition phase.

A migration guide will be provided to help developers adopt the directive seamlessly.

@lucasluizss lucasluizss added triage We discuss this topic in our internal weekly type: enhancement New feature or request labels Mar 4, 2025
@nuke-ellington
Copy link
Collaborator

Hello @lucasluizss,

Thank you for sharing this proposal with us.
Generally we are always open for possible improvements.

I would argue that there are some strong arguments against the directive based approach:

  • Reusability: Attaching button logic to any element will break A11y of the component in most cases. The ix-button is already a re-usable component and it is not clear to me why we cannot use it if we need the respective behavior.
  • Maintainability: Internally we use a BaseButton implementation that reduces redundancy already.
  • Improved Customisation: The premise of a design system is to provide a common look&feel across multiple projects. Attaching button logic to arbitrary elements runs the risk of going against that premise
  • Architecture: iX is build on Web Components. If we where to provide a directive based button for Angular it would require a specific implementation for this framework only, while Angular is not the sole focus of this library.

I don't see how to implement button directives in a way that improves the design system. I encourage you to convince me otherwise 🙂

@lucasluizss
Copy link
Author

Hey @nuke-ellington,
Alright, picture this: you're building a website, and you need a button, but not just any button. Maybe you want a stylish <div> or a simple <span> to trigger an action. That's where the ixAction directive shines. It gives you the freedom to turn almost any HTML element into a functional button, unlocking a world of creative possibilities. And don't worry about accessibility; the directive handles all the behind-the-scenes magic, ensuring everyone can use it, regardless of their needs.

Now, you might wonder, "If IX is built on Web Components, why add an Angular directive?" It's about providing a better experience for Angular developers. While Web Components ensure cross-framework compatibility, Angular directives offer a more integrated and idiomatic way to work within the Angular ecosystem. The ixAction directive leverages the existing framework-agnostic core logic of the Web Components, acting as a convenient wrapper that translates Angular-specific inputs into the underlying functionality. This way, we maintain the foundational benefits of Web Components while optimizing the developer experience within Angular's specific context.

If, after all this, the concept of the ixAction directive and its benefits still seem unclear, or if you feel it doesn't align with the project's direction, please don't hesitate to let meknow. I'm open to discussion and understand that not every idea will resonate with everyone. If we can't find common ground, we can always close the issue and move forward. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
triage We discuss this topic in our internal weekly type: enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants