Closed atirip closed 4 years ago
Element.prototype.remove
, so you are causing yourself a side effect into regular elements capabilities ... is there any specific reason to do that? 'cause append
would fail as well, and I'm not sure how this could be solved without degrading performance for everyone else that wouldn't pollute the global scope with a remove
leaked node (IDs leaks on the global scope) but also if you pass the form around, form.remove()
will fail too.No specific reason, just haven't been bitten by that before. Calling a button 'remove' is hardly a weird choice :-) I can easily change that to 'erase'. This is pretty sharp edge case, probably just 'form' tag weirdnesses needs to be warned in documentation or similar?
probably just 'form' tag weirdnesses needs to be warned in documentation or similar?
to be honest, if you have a form
with its inputs and these have names, form.name
would also shadow the native prototype.
It is definitively an edge case, but remove
is not an uncommon word, so I better write this in the documentation as caveat when it comes to forms, as I don't think having defensive code in comdiff core would be too beneficial in the wild.
Will create a section in either the README or the official documentation (or both).
For reference: https://twitter.com/niksy/status/1204768742330322944
I think this is a won't fix, as it's clear using bad names can lead to any sort of footgun, so I'll close it as won't fix and will put a note somewhere about this.
Agree. One suggestion though: maybe a specific error message? Like to check whether it is function you call and if not, then specific message. Ot try/catch. But as you can witness, only now I realise that libraries may need 'remove' and I have been doing this for quite many years :-)
if I put try/catches around I am penalizing critical core performance for an edge case, same if I touch that by an inch (using typeof
or anything else).
The thing is, anyone could overwrite any DOM native method and I don't want to be defensive about that, so remove
is not a special case, as even changing addEventListener
in a node would faile all over the place with 3rd parts libraries.
Later, when that form node needs to be dropped:
that crashes, as node.remove is node and not function