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

I'm not sure what exactly your perf tools do: I agree that explicitly proxying and transforming state is a good thing. However, it's not the only use case. Having built multiple apps in this manner, the issue is that this approach does not scale. When you have a component 10 layers deep and you need to change it's requirement, every component in the path in between now has to explicitly proxy the new data down, which makes this approach very brittle. 

This is not about "inter-component communication" (?). Only [events are used](https://github.com/pemrouz/vanilla#3-communication) for that in a "data down, actions up" paradigm. This is about either **a deep or recursive API** being necessary for the framework layer to manage updates. It might be beneficial to read more around things like Redux + React (but as aforementioned, it's not strictly just data, see for example [Om Next (30:36 onwards)](http://livestream.com/intentmedia/events/4386134) where they maintain a live index of all instances on the page).

The `composed` event is very relevant here: it's the symmetrical counterpart to this feature. Specifically, it enables dispatching an event which may pass through many layers all of whom do not need to explicitly re-emit the event. It's "upward piercing". 

> In such tests, there should be a test that verifies a given component dispatches an 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.

It appears you are erasing the problem here by suggesting to abandon integration tests for unit tests (two separate unit tests)? Testing end-to-end flows in an application happens across components. The introspection required by the testing layer, similar to the framework layer, transcends the component tree and it can't be expected to use the public API of components for this purpose. 

It's good to know Apple is opposed to open shadows. However, I think going forward, unless your goal is to sabotage the usability of open shadows, it's better to not mix the two problems. There's very little reason to oppose this hook for open shadows (especially given existence of upward piercing), and once you all work out how to make closed shadows more usable, then you can discuss deprecating open shadows altogether.

---
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-223458546