@adamdbradley do you know if there's a technical reason for this limitation? If not, does it make sense to offer a way to suppress this warning somehow?

[vb-oiko]

@adamdbradley do you know if there's a technical reason for this limitation? If not, does it make sense to offer a way to suppress this warning somehow?

Originally posted by @claviska in https://github.com/ionic-team/stencil/issues/2715#issuecomment-728253391

[vb-oiko]

First of all I would like to thank the stencil team for your hard work. I like the idea of stencil and it's implementation. I'm currently working on a uikit to be able to use styled form elements across our several projects. For example we created an input element which comprises a label, error message. etc. But to be able to use it it should emit standard events I guess. And using standard event names produces build warnings:

[ WARN  ]  Build Warn: ./src/components/w-input-text/w-input-text.tsx:83:12
           The event name conflicts with the "change" native DOM event name.

     L83:    @Event() change: EventEmitter<string>;

[ WARN  ]  Build Warn: ./src/components/w-input-text/w-input-text.tsx:85:12
           The event name conflicts with the "input" native DOM event name.

     L85:    @Event() input: EventEmitter<string>;

Is there a way to suppress that? Or am I doing something wrong?

[MarkChrisLevy]

@vb-oiko Native change event (or other native events) do not use CustomEvent (which is emitted by EventEmitter), but rather other implementation or basic Event class (for example there is no ChangeEvent, but there is e.g. ProgressEvent class for onProgress).

But you can fire almost any event you want, just use dispatchEvent

[scabana]

When @Event() is not used, it's hard to get good documentation on which events are actually emitted. I wouldn't mind handling the dispatchEvent on my own, but I'd like to retain the documentation though.

[lodybo]

So if I read this correctly, then this would be the proper way to send out a change event:

@Component({
  tag: 'my-input',
  shadow: true,
})
export class MyInput {
  @Element el: HTMLMyInputElement;

  triggerChangeEvent = (e: Event) => {
    this.el.dispatchEvent(e);
  }

  render() {
    <Host>
      <input
        onChange={this.triggerChangeEvent)
      />
    </Host>
  }
}

@scabana is correct in the fact that doing it this way means that the dispatched event will not be documented in components.d.ts and components.json. Especially with tools like Storybook, this would mean that we would see any @Props and @Events coming up, but in the example above we'd have no way of documenting that MyInput sends out a change event.

Also, could this be clarified in the docs? The first paragraph on the page about Events can let you assume that you'd need @Event to announce to the world that your component sends out (native) events.

[scabana]

I'd also add that @event is required to generate framework specific wrappers.

[lodybo]

I just found an example in the output-targets repo: https://github.com/ionic-team/stencil-ds-output-targets/blob/ad7e6605c372e6e98672a26ddf9e99f7343a9fc8/packages/example-project/component-library/src/components/my-input/my-input.tsx

In that file the my-input component has defined its own myChange, myInput, myFocus, and myBlur events instead of using dispatchEvent() to send out those events. Would this be preferable to my example above?

[MarkChrisLevy]

@lodybo dispatchEvent shouldn't be used at all if you don't need to send "native" events. Other events should be declared and send just like they are described in the docs.

[lodybo]

@MarkChrisLevy Yes, I understand. My question was about which option would be preferred of we have a Stencil component that is just a wrapper with styles around an input field:

• create our own myChange, myFocus, etc. events using the @Event decorator?
• use dispatchEvent to fire "native" events, such as change (which is just an Event) and focus (like in my example above)

If that component would have any custom events of its own, like myFieldIsEnteredAndValidated, that would always be done through Stencil's @Event decorator.

I hope that makes my question a bit clearer?

[MarkChrisLevy]

@lodybo Imho it is always better to use @Event decorator, as it is easier, cleaner and there are framework bindings. My solution to use dispatchEvent was only for cases, when it is necessary to emit native events (e.g. because there is a global listener of native event).

[lodybo]

@MarkChrisLevy I think I understand what you mean, and why Stencil prefers it that way.

In that case I think a clarification (with maybe some examples) would be a good idea. It could prevent the assumption that web components should rely on the native events, instead of defining their own version of those events. I see that you can propose edits on the documentation page, so I can give it a try later next week.

[MarkChrisLevy]

@lodybo Just to clarify: all stencil events are native DOM events, but when using @Event decorator you cannot emit standard/basic DOM events like change or click - you can emit any other (usually with name prefix like ion, e.g. ionChange), but they are still native DOM events.

[lodybo]

Yeah I saw when I read through the source code for @Event. We are working towards moving the events for our input fields towards @Event decorators. Thank you!

[danyball]

My question just refers to the input event: A angular consumer normally uses [(ngModel)] to bind values to a form element like . So i added @Event() input to my component. Because angular ngModel is listening internally to the "input" event. This is why it is not possible to use another named event like "xy-input".

Shouldn't we remove the warning "The event name conflicts with the "input" native DOM event name."?

[mtempranoWalla]

Has there been any further discussion regarding this? Seeing as it's not closed, is there any plan to remove said warning?

[wes337]

This is a pretty big drawback to using Stencil. I'd like to have event listeners on my web components and have them used as one would typically expect:

<MyStencilInput onFocus={this.handleFocus} />

But because of this 'warning', I'm pushed to do something like:

<MyStencilInput myFocus={this.handleFocus} />

Which is awkward and possibly confusing when somebody goes to implement my Stencil component.

[schirrel]

I am passing the same thing. I need to build a component that should have a change/input event name, like native, we are using vue 2 so we need this to can use v-model, but this warning keeps showing. I am current using dispatch with custom event, but thats not seems appropriate. Anyone on stencil team has update on this? @alicewriteswrongs @rwaskiewicz @tanner-reits

[felipefialho]

Is there some news about it? Is it a good idea to keep the native event to do things like click inside buttons for example but it generates a warning like it

The event name conflicts with the "click" native DOM event name.