Re: [webcomponents] Change deepPath() back to path (a FrozenArray<EventTarget> attribute) (#428)

Having properties that return a new object every time is an antipattern for several reasons:

1. It's very inefficient.  Consider what typical code that walks event.path would look like and when it would create new objects.
2. It breaks consumers who might want to use the property value as a key in a WeakMap (less of an issue for this particular case, I agree, since you're not likely to be dealing with multiple event paths at once).
3. It breaks consumers who add properties to the return value only to see them disappear.  Note that this does not affect `FrozenArray`, because it's frozen so you can't add properties.
4. Less importantly in practical terms, it violates the `a.b === a.b` constraint.  I say less importantly, because just having `a.b = NaN` also violates that constraint.  The expression involving `===` is just a shorthand for the "no surprises" aspect of property getters: they should generally not be super-expensive (the web platform fails this in a bunch of cases, yes) and they should not allocate new things each time you call them (the web platform is a _bit_ better here).

There are probably more reasons that I can't think of right now this time of night.  Again, this has been discussed to death for years now...

It's unfortunate that after this has all been known for years the shadow DOM implementors in Blink decided to add and then ship in release the "create a new object each time" behavior for `path`.

Anyway, having a `FrozenArray` attribute that changes at well-defined points (like whenever the current target changes, or event dispatch starts or ends) is quite feasible if we do want to go that route.

I would be somewhat opposed to implementing the "`path` creates a new object every time` behavior unless people think it's actually needed for web compat.


---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/428#issuecomment-194685509