Angular component

[jackocnr]

Hi @GuiEpi, how are things? Would you mind sanity-checking these Angular commits for me when you have a second?

In master:

• fix angular cmp so it only fires change handlers when values actually change

In v27 branch (BREAKING CHANGES!):

• angular cmp: default export, to bring in line with other cmps
• angular cmp: support individual option props

That last one changes from this:
<intl-tel-input [initOptions]="{ initialCountry: 'us' }" />
to this:
<intl-tel-input initialCountry="us" />

I'd really appreciate your thoughts!

[GuiEpi]

Hello, I am very well, and you?

I tested both the main branch and v27 and didn't find any problems. Everything works as expected.

Regarding the changes:

• The fix for change handlers in master looks good
• The default export in v27 makes sense for consistency with other components
• The individual option props are much cleaner and more intuitive than the initOptions object

I did notice a UX issue in the form validation example while testing. I've created PR #2144 with a fix and detailed explanation of the problem. Feel free to review when you have time!

Thanks for your work on v27!

[jackocnr]

I have been ill this week, but feeling much better now, thank you!

Thanks so much for your feedback. And for spotting that bug and putting together a fix so quickly 💐

One more question for you: I notice the way inputProps are applied with this component - using setAttribute, which makes sense as I see all the event listeners are handled differently with Angular. So I was wondering: do you think it's a bit misleading to call this inputProps? Maybe for the Angular component, we should call it inputAttributes? If we want to change any names, now is the time, with v27!

[GuiEpi]

I think you are absolutely right.
Based on your suggestion about inputProps → inputAttributes, I'd like to propose a more comprehensive improvement:

Proposed Changes

1. Remove inputProps entirely

2. Add explicit @Input() props for common use cases cited in the documentation playground:

• placeholder (string)
• readonly (boolean)
• Keep existing disabled and initialValue

3. Add inputAttributes for edge cases:

• ARIA attributes (aria-label, aria-describedby, etc.)
• Data attributes (data-testid, data-track, etc.)
• Other HTML attributes without DOM properties

New Usage (v27)

<!-- Common properties: explicit and type-safe -->
<intl-tel-input 
  placeholder="Enter phone number"
  [readonly]="isReadonly"
  [disabled]="isDisabled"
  initialValue="+33612345678"
  [inputAttributes]="{ 'aria-label': 'Phone', 'data-testid': 'phone-input' }"
/>

[GuiEpi]

I have a question for you as well: why not split AllOptions into sub-options, similar to the playground: CountryOptions, UserInterfaceOptions, ... ?

[jackocnr]

why not split AllOptions into sub-options

Can you tell me more about what you mean by this? What would this change? (I really appreciate your thoughts!)

[GuiEpi]

Actually, I think it made more sense in versions < v27, but now that we have an @Input per option, I think what I'm proposing loses its appeal.

It would have looked something like this:

@Input() countryOptions: CountryOptions = {};
@Input() userInterfaceOptions: UserInterfaceOptions = {};
@Input() placeholderOptions: PlaceholderOptions = {};
...

instead of:

@Input() initOptions: AllOptions = {};

But once again, I think it loses its meaning with v27 and that my question is a bit "silly".

[GuiEpi]

By the way, I wanted to tell you about Claude for Open Source: https://claude.com/contact-sales/claude-for-oss
They offer free access to Claude Pro to managers of popular open source projects. Given the popularity of intl-tel-input, you are eligible. I thought you might be interested.

[jackocnr]

That is so thoughtful of you, thank you! 🙏🏻