refactor: do not pollute markup with useless id

[lmiller1990]

Related: #219

@afontcu seems we can remove this id. I am not sure about the div - what should we be attaching to?

Also, does testing library use attachTo by default? We need something to mount on - if you are using attachTo, however, maybe we can use that element to mount on, instead of creating our own DIV here?

[afontcu]

Hi!

This is the solution I came up with, which makes all related-tests pass at once: https://github.com/testing-library/vue-testing-library/pull/137/files#diff-4f8b5837e5c68e71852f1c3f41f2e98201426d45a94bd7767cddfc98ccd02fc5R66-R68

re attachTo, I'm currently attaching it to container, just as testing lib for Vue 2 (no changes there): https://github.com/testing-library/vue-testing-library/pull/137/files#diff-4f8b5837e5c68e71852f1c3f41f2e98201426d45a94bd7767cddfc98ccd02fc5R57

Right now, the PR testing-library/vue-testing-library#137 has all non commented out tests passing.

if you are using attachTo, however, maybe we can use that element to mount on, instead of creating our own DIV here?

This is probably… sensible? I mean, people asked for special behavior when document.body is provided to attachTo. What's the point of letting people set a custom attachTo value, and then wrap it up again in a div? 🤔

[lmiller1990]

I could be wrong about how attachTo is currently working, that might already be the behavior. I will check.

Either way this fix is still good. Seems like your fix in testing library is okay, is there anything else blocking the Vue 3 integration?

[afontcu]

is there anything else blocking the Vue 3 integration?

Not really, I'm a bit worried about the third render parameter – a way to access the Vue instance of the component under testing, and how this translates to Vue 3 concept of "app" instead of vue instances:

// testing lib with 2.x
render(Component, {}, vue => vue.use(AnAwesomePlugin))

options.global works in a large chunk of situations (this is going to be quite a big breaking change – not about behavior, but about setup):

// testing lib with 3.x
render(Component, { global: { plugins: [AnAwesomePlugin] } })

however some people did quite complex trickery with the Vue instance. We'll see if the global options can keep it up, or if other libraries (such as Vue Apollo in the example) provide a "Vue-3 way" of achieving the same thing.

Also, integration with VueRouter-next is not there yet, given that we haven't decided how to tackle it in VTU-next (AFAICT). I might go ahead and simply install it as a plugin, and see what happens in the wild.

I guess I'll release an alpha version in the next channel soon, and see if people run into some issues. This might help dogfooding VTU-next, too! :)

[lmiller1990]

localVue changes should mostly be fine with just global.plugins. The localVue change is inevitably a big breaking change for everyone; we can't really avoid this, it's just how Vue 3 works now. It's not really a behavior breaking change, just an API breaking change.

And yep - my experience so far is predicting things is hard, better just to get something out there and let people report issues.