Re: [WICG/webcomponents] Form-associated custom elements: being a submit button (#814)

bahrus left a comment (WICG/webcomponents#814)

@justinfagnani  

>  If we ever get "behaviors" that add instance properties, then that would be most easily explainable by putting something on the prototype chain with those properties, rather than monkey-patching the instance. I'm not sure if a button behavior would add additional methods, but I could see some behavior eventually needing to do that.

I'll look into providing the ability to add behaviors into the prototype chain in my proposal, following the approach suggested by  @EisenbergEffect , when that makes more sense to do.

I guess in the more global picture, I concur more with @EisenbergEffect.  I still think providing a decorator pattern into the platform for cross cutting concerns would be a great boon. As @EisenbergEffect  points out, it has proven itself over many decades.  It has essentially been widely adopted across the board, across multiple frameworks, old and new, for more than custom elements.  It allows for progressive enhancement (in the sense of preventing render blocking).   I recognize, unfortunately, that there will be a tendency to say "now that we provided this functionality, we can ignore the other pressing use cases", which unfortunately I see now more of @EisenbergEffect 's concerns.

And it can avoid namespace clashes more effectively.  Mixins [hardcode property names](https://legacy.reactjs.org/blog/2016/07/13/mixins-considered-harmful.html), and would tend to make dependencies overly brittle.  They are more tightly coupled.  My vote is for all the above, in other words.  Symbols could be used to prevent some clashes, but symbols break when there are different versions of the same library floating around.  They have their place, and given the historical pattern of the web, for an element to "be like a button", the mixin pattern seems like the more pragmatic approach, in order to more effectively emulate the built-in support.  Or to @EisenbergEffect 's point, maybe we should take a hard look at what we've done through pure inertia and start correcting course, long term.

It doesn't make sense, for example, to "hardcode" binding support into an element, to take one example, does it?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/WICG/webcomponents/issues/814#issuecomment-3393788553
You are receiving this because you are subscribed to this thread.

Message ID: <WICG/webcomponents/issues/814/3393788553@github.com>