POC extending without plugin #55
Conversation
| import { mount, VueWrapper, config } from '../../src' | ||
| import Hello from '../components/Hello.vue' | ||
| // add a method to the VueWrapper | ||
| declare module '../../src/vue-wrapper' { |
There was a problem hiding this comment.
IDK if thats how you should do it, just used the first thing I saw.
There was a problem hiding this comment.
I think this is something users would normally do in an index.d.ts file on the top level
| } | ||
| } | ||
|
|
||
| VueWrapper.prototype.name = function () { |
There was a problem hiding this comment.
The cool thing here is, all the instanced will get the function as its native.
| return this.componentVM.$.type.name | ||
| } | ||
|
|
||
| config.plugins.VueWrapper.lowerCaseName = function lowerCaseName( |
There was a problem hiding this comment.
This is a little easier to grasp for people with little prototype knowledge, but has a little higher memory cost I guess?
There was a problem hiding this comment.
I think people who want to write an extension prob know enough to learn about a prototype
| plugins: { | ||
| VueWrapper: {} as any, | ||
| DOMWrapper: {} | ||
| } |
There was a problem hiding this comment.
I will look into typing this! I want to get better as TS, but I think this is fine for now, nice
|
|
||
| // plugins hook | ||
| Object.entries(config.plugins.VueWrapper).forEach( | ||
| ([name, handler]: [string, () => any]) => { |
There was a problem hiding this comment.
lol, nice! you can also use unknown for the return type, reflecting an unknown value, both fine
| import { mount, VueWrapper, config } from '../../src' | ||
| import Hello from '../components/Hello.vue' | ||
| // add a method to the VueWrapper | ||
| declare module '../../src/vue-wrapper' { |
There was a problem hiding this comment.
I think this is something users would normally do in an index.d.ts file on the top level
| return this.componentVM.$.type.name | ||
| } | ||
|
|
||
| config.plugins.VueWrapper.lowerCaseName = function lowerCaseName( |
There was a problem hiding this comment.
I think people who want to write an extension prob know enough to learn about a prototype
|
@afontcu @JessicaSachs What is your opinion? Should we promote |
update: i'm just dumb XD Thanks for this! |
|
Haha no no, that was just a way to test whether they work. One uses the method added prior. How you access the internals is the same in both cases. |
Yeah okay makes sense hahaha. I do think that relying on prototypes "feels" hacky, even though I'm OK with this given that it's an advanced feature and that it should be documented 👍 |
|
So if we are going with the |
|
We just need to export DOMWrapper and VueWrapper and that should be it. We should also test this after it is transpiled, so that means when it is published as a package. |
|
Ok, want to update this to just export those two? I made a ticket for some e2e tests: #68 |
|
@dobromir-hristov should we export DOMWrapper too? |
|
I guess this would become the "right" approach to extend VTU as Vue Testing Library does? I mean, the way to add "custom" matchers and other stuff. I'll try to give this a go during the weekend and come back to you folks with the result 👍 |
|
So I just finished toying around. I found the API a bit awkward at first. I'll see if there's a pattern that feels more natural. I mostly found that I just wanted the Before: config.plugins.VueWrapper.name = function name() {
return this.componentVM.$.type.name
}
config.plugins.VueWrapper.lowerCaseName = function lowerCaseName() {
return this.name().toLocaleLowerCase()
}Possible solution to enclose the wrapper instance? config.plugins.VueWrapper.extend((wrapper) => ({
lowerCaseName: () => wrapper.name().toLocaleLowerCase(),
name: () => wrapper.componentVM.$.type.name
})The other thing I'd like to solve is the ability to use reactive properties so that not everything has to be a method. I'll continue toying with that. |
|
So no prototype extension? Private field would not be accessible if passed as a param. |
|
You would still apply it to the prototype when you install the plugin in the constructor. I'm mostly just concerned with getting a reference to |
|
Are we leaning towards @JessicaSachs implementation for a plug-in or this one? Let's pick one and focus on that. I am excited to write some plug-ins (mainly |
This is just an example how one can extend VTU with either normal prototype attachment, or via a dedicated API.
Please give me your opinions on which one you think is better?