Shallow mount drops attributes on stubbed components

[Stoom]

Version

1.0.0-beta.30

Reproduction link

https://github.com/Stoom/vuetify-test-utils-beta30-example

Steps to reproduce

• Create new project
• Add vuetify
• Use a vuetify component like v-tooltip
• Stub out to get scoped slot
• Assert an attribute is on the stubbed element

What is expected?

It to copy over the current attributes

What is actually happening?

custom prop attributes are lost

---

This works on beta28 but broke in beta29 and beta30

[JessicaSachs]

@Stoom Great bug report. Thank you for the detailed writeup and extra info about what version broke it.

[Stoom]

Any thoughts on where this might be happening?

[JessicaSachs]

Spent a large portion of the night trying to debug. I think innerHTML of the element shows there is no issue in the actual render... so I think the issue is in the wrapper.attributes method.

I'm gonna be offline for 2 days, but here is what I've gotten to... (using VTU as the sandbox)

// stubs.spec.js
  it.only('replaces component with a component and inherits attributes', () => {
    const mounted = sandbox.stub()
    const Stub = {
      template: '<div />',
      mounted
    }
    const wrapper = mountingMethod(ComponentWithNestedChildrenAndAttributes, {
      stubs: {
        ChildComponent: Stub
      }
    })
    const childStub = wrapper.find(Stub)
    console.error('wrapper innerhtml', wrapper.vm.$el.innerHTML) // contains 'bottom' and other attrs
    console.error('attributes on childStub', childStub.attributes('bottom')) // undefined
  })

and then ComponentWithNestedChildrenAndAttributes inside of test/resources/components

<template>
  <div>
    <span>
      <child-component my-html-attribute bottom />
      <component-with-lifecycle-hooks another-html-attribute />
    </span>
  </div>
</template>

<script>
import ComponentWithChild from './component-with-child.vue'
import ComponentWithLifecycleHooks from './component-with-lifecycle-hooks.vue'

export default {
  name: 'component-with-nested-children',
  components: {
    ChildComponent: ComponentWithChild,
    ComponentWithLifecycleHooks
  }
}
</script>

[StummeJ]

@JessicaSachs did you have any other information on this? I'm happy to try to help find the issue 😺

[JessicaSachs]

Heyo @StummeJ! Thanks for the ping. If you'd like to try picking this up, feel free.

I've been busy with VueConf and catching up w/ my job. The latest I have is the failing test that I wrote above.

[Stoom]

Okay, so I looked back at my example and the test code you've written. It looks like with the latest dev everything works as expected. Where I see the issue is when I feed a string into the stubs object

    const wrapper = mountingMethod(ComponentWithNestedChildrenAndAttributes, {
      stubs: {
        SlotComponent: Stub,
        ChildComponent: '<div id="child-component"/>'
      }
    })

When doing this it will not error and renders without props included in the attributes. Simply replacing the string with { template: '<div id="child-component"/>' } then the test passes as expected.

@JessicaSachs my question now is, should the stubs property be able to take in a string, and if so is there something it's doing differently with a pure string over an object with the string in the template property?

[lmiller1990]

I think that when you pass a string like that, Vue thinks it is literally a string, like "Hello" or "Foo".

What might be happening here is it is not actually rendering a DOM element, but a string that looks like a DOM - it is escaping the < and rendering a literal <. Eg, it compiles to h('<div id....') as opposed to h('div', { id: ... }). It then inserts it via innerText, possibly.

So stubs can take a string, I think, but it is just that - a string, not a HTML template - so this is intended and correct behavior, I guess?

[StummeJ]

@lmiller1990 it ends up going through the vue template compiler, so things like slots end up getting rendered correctly. The output of the render functions match between a string and a {template: string} stub. If you do Component: true then it gets a much more complex render function that applies $attrs and $props to the html attributes.

[lmiller1990]

Sure, but if you just pass a string, I think it goes through the compiler anyway, becoming h('whatever text'). There is no second argument, which is where attrs and props would usually go.

[Stoom]

Sorry for the multiple accounts, @StummeJ is for my professional job... That kind of makes sense, but it seems like there are different behaviors given similar render functions...

---

SlotComponent: { template: '<div id="SlotComponent"/>' }

function anonymous() {
  with(this){return _c('div',{attrs:{"id":"SlotComponent"}})}
}

---

ChildComponent: '<div id="child-component"/>'

function anonymous() {
  with(this){return _c('div',{attrs:{"id":"child-component"}})}
}

---

OriginalComponent: true

function render(h, context) {
      var this$1 = this;

      return h(tagName, {
        ref: componentOptions.functional ? context.data.ref : undefined,
        attrs: componentOptions.functional ? Object.assign({}, context.props, context.data.attrs, { class: createClassString(context.data.staticClass, context.data.class) }) : Object.assign({}, this.$props)
      }, context ? context.children : this.$options._renderChildren || getScopedSlotRenderFunctions(this).map(function (x) {
        return this$1.$options.parent._vnode.data.scopedSlots[x]();
      }));
    }

output:

<div>
  <span>
    <div id="SlotComponent" prop1="foobar" prop2="fizzbuzz"></div>
    <div id="child-component"></div>
    <originalcomponent-stub prop2="fizzbuzz" prop1="foobar"></originalcomponent-stub> 
 </span>
</div>

[lmiller1990]

Oh, I did not realize the second one rendered like that. Interesting.

Rather than making the codebase more complex to support passing a <div id="blah />, I think it's probably find to just update the docs and remove the example saying you can pass a string that is valid HTML. It seems like passing a { template } is working as expected, as you noted. What do you think? I'm a fan of keeping it simple, rather than providing 3-4 different ways to accomplish the same thing.