> Also from one of your links, the second half of the following statement,
> if accurate, worries me:
>
> "We should not use output and input names that collide with either a
> native property/event name or even an input/output name used by any
> other component or directive."
>
Yeah, I question that second-half comment. Never heard that before.
Assuming your not masking browser built-ins, I fail to see how this could
be an issue. I have many pages with numerous onChange's and I've never had
any odd behavior.
> I'm going to need to play around with it a little more to actually get a
> feel for different approaches. Maybe the tried and true eg- prefix
> (egClick, egChange, etc.) could be another option.
>
I could see that. It might also encourage consistency in how event
handlers of a given type behave.
>
> P.S. I reviewed and pushed the first chunk of this branch (#1818288) to
> master and rel_3_3, and will continue with the next chunk. Thanks,
> Bill!
>
> /angular. io/guide/ styleguide# dont-prefix- output- properties
> Oddly enough, they use a lot of examples like (verb), and as a commenter
> pointed out, they specifically say to not use onVerb for output
> properties in the Angular style guide:
>
> https:/
Yes, I'm fully on board with dropping the on's.
> Also from one of your links, the second half of the following statement,
> if accurate, worries me:
>
> "We should not use output and input names that collide with either a
> native property/event name or even an input/output name used by any
> other component or directive."
>
Yeah, I question that second-half comment. Never heard that before.
Assuming your not masking browser built-ins, I fail to see how this could
be an issue. I have many pages with numerous onChange's and I've never had
any odd behavior.
> I'm going to need to play around with it a little more to actually get a
> feel for different approaches. Maybe the tried and true eg- prefix
> (egClick, egChange, etc.) could be another option.
>
I could see that. It might also encourage consistency in how event
handlers of a given type behave.
>
> P.S. I reviewed and pushed the first chunk of this branch (#1818288) to
> master and rel_3_3, and will continue with the next chunk. Thanks,
> Bill!
>
Thanks, Dan!