Re: [w3c/webcomponents] Support /deep/ in static profile (bugzilla: 28591) (#78)

> You still want to be able to benefit from things like style encapsulation, but there is more involved with application-level components, like state management.

I've been using shadow DOM to write our performance tracking tool, and many of "components" have to track dozens of states.  Yet, I've never found it useful having to reach into some other component's shadow tree in order to get access to those states.  In practice, all those states are stored in some sort of JavaScript objects and properties, and components should be exposing some public API to access those states.

> It's reasonable to dispatch an event in one part of the application and make assertions about what changed on the other side.

In such tests, there should be a test that verifies a given component dispatches and event, and a separate test which verifies that the given component responds to the event.  You could even manually inspect those components' shadow trees during testing but that doesn't require anything akin to `querySelectorAll` since you're unlikely to be testing every single component simultaneously.

> The view that everything should be controllable and observable from the top-level component's public API of the component is obviously impractical and brittle (every subcomponent has to proxy everything).

There is [`composed` option](https://dom.spec.whatwg.org/#dictdef-eventinit) in `EventInit` that makes the event propagate across shadow boundaries.  That should be sufficient for that kind of inter-component communications.  Using `/deep/` to do that kind of inter-component communication is *precisely* the anti-pattern we want to discourage.

> Is the design goal of shadows to simply maximize encapsulation so that they are not useful throughout an application and are only useful as third-party leaf nodes?

I disagree with your premise that maximizing encapsulation is not useful for components within an application given my experience of having successfully written a web app that's made up of dozens of closed shadow tree components.

Having said that, Apple's position has always been that open mode of shadow DOM is a mistake.  The only reason we have "open mode" shadow tree is because we made a compromise to keep both modes without a default during [April 2015 F2F meeting](http://www.w3.org/2015/04/24-webapps-minutes.html) for the sake of moving shadow DOM API as a whole forward.

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