-
Notifications
You must be signed in to change notification settings - Fork 113
feat: Expose the component instance #250
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Expose the component instance #250
Conversation
@afontcu would it be possible for you to take a look at this PR. Is it possible that this feature could be merged? It would help fix some issues with using testing-library and Nuxt that we've run into at Openverse.
@afontcu would it be possible for you to take a look at this PR. Is it possible that this feature could be merged? It would help fix some issues with using testing-library and Nuxt that we've run into at Openverse.
Hi! And sorry for the late reply, busy weeks and holidays and so on :) And thank you for your kind words! It's great to hear you folks at Wordpress are using it. How humbling! 😄
I'm afraid this is unlikely to get merged as it kind of breaks two of the main principles for Vue Testing Lib:
- Writing tests that resembled the way the software is used.
- Have a symmetrical API with other testing-library flavours such as React – at least, as much as possible.
Sadly, by exposing vm we'd be kind of breaking both of them. I know (1) is not that clear here, as we're talking about setting up the right test env. However, exposing vm opens the door for a lot of arbitrary internal modifications of the component. That is, your use case is valid and hooking into Nuxt lifecycles might be sensible, but for instance one could also call private methods from vm
To solve your use case, maybe using the official Vue Test Utils library is a valid solution, as suggested in the linked issue? It exposes a myriad of options that would allow you to modify the vm while keeping Vue Testing Library closed to implementation details
That being said, if we find enough compelling cases for it we could reevaluate the situation and integrate some workaround.
@afontcu Okay, thanks for the thoughtful response. I kind of figured that might be what the answer would be 🙂 I'll close this PR and we'll continue to use the regular Vue Test Utils directly in these cases.
Thanks again for all your hard work!
Thanks for the awesome project! I've really enjoyed using it over at WordPress/Gutenberg and now introducing it to WordPress/openverse-frontend. It's been a great tool for learning and teaching people how to test with a focus on accessibility. Again, thanks so much!
I ran into this issue today so I decided to open a PR that would help me solve the issue, hope that's okay! This would also solve some of the issues found in this issue: #92
By exposing the
vmfrom the@vue/test-utilswrapper, it'll allow doing things like callingComponent.fetch.call(wrapper.vm)which is necessary becuase by default Vue doesn't call the "extra" Nuxt lifecycle methods (more about those here https://nuxtjs.org/docs/2.x/components-glossary/pages-fetch)Maybe there's another more complex approach that would work more seamlessly (like adding a plugin that calls these methods for you or something) but this seems like the simplest option, just exposing the component instance that you'd get if you just used
@vue/test-utilsdirectly.