@linusborg
Nothing here yet.
Nothing here yet.
No blogs yet.
I think you are talking about implementations of the web components standard, and libraries like polymer that use it. Currently web components are an emerging standard and we don't feel that the case is settled enough to commit to it. Also, there's still open questions about how certain features of Vue could be implemented in web components as well as we have them in Vue itself. But with vue-custom-element , you can transform Vue components into web components, so it's possible if you really want to.
In our case we need to do that. We have complete control over 3rd party code, and we rewrite stuff that misbehaves. If that's the case, you are free and certainly able to fork Vue and remove the code that keeps it from mounting to body , or even better, submit a well-tested PR on github, along with a guide on how to deal with the problems of 3rd party-code competing for body . We however have to focus our limited resources on supporting the needs of the larger community. As mounting to body can create problems that, as you explained, have to be worked around in 3rd-party code, we don't feel like it's a good idea to implement it as it will certainly introduce subtle bugs for many of our users that have to rely on 3rd party code they can't control. As a sidenote, a little less agressive tone would help the conversation. And dan is awesome :)
I assume your question is how to log data to the console and read it? The issue you experience is due to Vue's Reactivity system, which extends objects with getter and setter methods to track changes and react to them. However, When I log something to the console, it's usually quite readable. If you really need a plain output, you can use JSON.parse/stringify to create fresh, plain object. I demo both things here: https://jsfiddle.net/x8nhrf0c/1/ Also, we recommend to use your devtools in Chrome or Firefox to inspect your component's data - it formats it nicely for you.
Hm, we haven't found a lot of problems with devtools even in big apps, but there are of course some scenarios where performance can become a problem, mostly with very large datasets or high frequency commits to the store, e.g. from a socket. If that breaks the devtools for you, chances are it will also be problematic for your app's general performance, at least on slower devices. so it might be worthwhile to cache incoming socket messages in an array and do bulk commits with a throttled function. Open a thread on the forum and we can discuss this further. That also counts for the second questions, which I don't think I can answer here with the information provided.