Co to są zalecenia dotyczące nazw zdarzeń @Output (aby zapobiec kolizji nazwy lokalnego zdarzenia)?

Question

Grałem z komponentami Angular 2 i ich kompozycjami i wpadłem w paskudne zachowanie, które jest spowodowane rodzimym propagowaniem zdarzeń i kolizją @Output.

Mam składnik app-formularz z formularza w szablonie

<form (ngSubmit)="submitButtonClicked($event)"> 
    <input type="text"/> 
    <button type="submit">Send</button> 
</form> 

Używam tego komponentu formularz w APP-middle komponentu, który ma własne emitera zdarzeń z nazwą przedstawienia.

@Component({ 
    selector: 'app-middle', 
    templateUrl: './middle.component.html', 
    styleUrls: ['./middle.component.css'] 
}) 
export class MiddleComponent implements OnInit { 

    @Output() submit = new EventEmitter<string>(); 

    constructor() { } 

    emitSubmitEvent() { 
    this.submit.emit("some data"); 
    } 

} 

szablon:

<div> 

    <app-form></app-form> 

</div> 

I app komponent z szablonu:

<app-middle (submit)="submitListener($event)"></app-middle> 

Teraz submitListener zostanie wywołana

• kiedy złożyć na app-środkowej nazywa (pożądane zachowanie)
• gdy formularz jest składany, ponieważ rodzimy wydarzenie bańka na górę („pasożytniczy” zachowanie)

Przypuszczam, „pasożytniczy” zachowanie oparte jest na razie DOM pęcherzyków. Mogę zatrzymać go przez event.stopPropagation() w submitButtonClicked obsługi, ale jeśli zapomniałem zatrzymać go, dostaję dość brzydkie błędy.

Generalnie uważam to zachowanie za dość niebezpieczne. Jeśli się nie mylę, każda procedura obsługi wyrażeń wiążących zdarzenia może być potencjalnie nazywana "pasożytniczą" przez natywne zdarzenie z wewnętrznych komponentów. jeśli ma taką samą nazwę jak każdy zdarzeń DOM (https://developer.mozilla.org/en-US/docs/Web/Events) i ja nie mówię o kompatybilność w przód ....

sam problem można zobaczyć tutaj: https://bitbucket.org/winsik/submit-event-issue/src

Czy napotkasz ten problem? Jak nazywasz swoje @Outputs?

Answer 1

Jestem prefiksem @Output zdarzeń z nazwami moich komponentów, który wydaje się działać całkiem dobrze i zapewnić spójną i przejrzystą konwencję, która pozwala uniknąć problemów, które opisujesz. Załóżmy na przykład, że mam składnik o nazwie, np. TurnEditorComponent - @Output zdarzenia mogą być nazywane turnEditorChange, turnEditorFocus, turnEditorBlur i tak dalej.