These are very good questions and something that hasn’t been addressed well in the WC community that Rob and some others are doing a very good job of with their recent posts.
Re #1: We had this specific problem. We wanted props down, events up but CEs didn’t support that out of the box. We built Skate as a generic solution to CEs prior to this need and then decided to be opinionated and fold in Incremental DOM to get the props down aspect. React was a huge influence in our decisions.
Since Skate encapsulates the virtual DOM approach and uses DOM events for reactivity, it works everywhere (and with multiple versions of itself on the page). You get the nice FRP model, but it doesn’t leak outside of the component. To everyone consuming your component, it’s just a normal DOM element.
Re #2: We have also had to address this problem because of #1. The way we’ve done it is to rely on NPM deduping, since we publish our components there. Thus, all components have a hard dependency on a fuzzy version. You could peer dependency them, too. If you’re not distributing your components like that, you can force the consumer to globally install the dependency, or you could bundle a single instance of the dependency with your 20 components into a single package. The latter is more desirable if not using NPM because if there is another Skate on the page, there’s no conflict and then you’re not relying on globals. That said, both work. The viability of this solution depends also on the size of the library and the payload you’re willing to send down the pipe. In our case — since Skate is quite small — the edge case of having more than one version is palatable as we’d strive mostly to have a single version on the page, but if not, things at least still work and we have time to work on deduping.
This problem isn’t restricted to web component libraries, either. If you decided to use the raw APIs, you’d probably end up having to include other libraries to fill in where an abstraction normally would. You’d then start running into the same issues.
We’re still looking at ways to improve on #1 and to ease the pain of #2, so if you have any feedback, we’d love to hear it.
