`Vue.nextTick()` required with transitions.

[autumnwoodberry]

Version

1.0.0-beta

Reproduction link

https://github.com/autumnwoodberry/vtu

Steps to reproduce

Nest some v-if:

<transition>
  <div v-if="a">
    <transition v-if="b"></transition>
    <transition v-if="!b"></transition>
  </div>
</transition>

test('output', () => {
    wrapper.setData({
      a: true,
      b: true
    });

    expect(wrapper.vm.a).toBe(true)
    expect(wrapper.vm.b).toBe(true)
    expect(wrapper.html()).toMatchSnapshot()
})

What is expected?

wrapper.html() returns the updated markup.

What is actually happening?

wrapper.html() returns outdated markup unless the test is changed to:

test('output', () => {
    wrapper.setData({
      a: true,
      b: true
    });

    expect(wrapper.vm.a).toBe(true)
    expect(wrapper.vm.b).toBe(true)
    Vue.nextTick(() => {
      expect(wrapper.html()).toMatchSnapshot()
    })
})

[eddyerburgh]

Thanks for the detailed bug report 😄

This is an issue with transitions, I'll look into it over the next few days

[eddyerburgh]

I think the solution to this is to stub the transition and transition-group components.

We have 3 options:

1. leave it to the user to stub using the stubs mount option
2. Provide a transition and transition-group stub components, for the user to pass in the stubs option
3. Stub transition and transition group by default inside mount

I'm leaning towards option 2.

I'd be happy with option 3. I don't use transition very often, so I'm not sure if there's be a use case for people testing unstubbed transitions? I'd be interested to hear others thoughts.

[autumnwoodberry]

I like the "opt-in" option best as well and I think it keeps unexpected internal behavior to a minimum.

It might be nice to have a config somewhere so you can turn it on globally. I use transitions enough that it would be nice to that that option.

[eddyerburgh]

That's a good idea @autumnwoodberry . We could make a global config, like Vue has.

[autumnwoodberry]

I'm going to be pretty busy the next few days, so I will just leave a couple more thoughts I had:

• I'm actualy not sure what wrapper.setData({ a: true }) does vs wrapper.vm.a = true
• If we made setData() async, or provided an async version or async option for it, it might be a more intuitive solution.

await wrapper.setData({ a: true })

expect(wrapper.vm.a).toBe(true);
expect(wrapper.html()).toMatchSnapshot();

• Whatever gets decided, I think this should all get mentioned in the setData() docs section.

[eddyerburgh]

I'm actualy not sure what wrapper.setData({ a: true }) does vs wrapper.vm.a = true

setData sets the data and calls update.

If we made setData() async, or provided an async version or async option for it, it might be a more intuitive solution.

I don't think we should make setData async. Synchronous updating makes unit tests simpler to write and easier to read. I agree, it can be confusing for experienced Vue users who expect async updating, but I think that for the majority of users they would expect setData to update the Vue instance, which it does for everything except transitions. Which is why I'm tempted to stub transitions by default, and make it an opt-out feature.

Whatever gets decided, I think this should all get mentioned in the setData() docs section.

This isn't really a setData issue, it's to do with update. I agree though that this can be confusing.
I think we should link to update in all methods that call update, and add a gotchas section.

[autumnwoodberry]

Ok yes, I see - that makes perfect sense.

[eddyerburgh]

I just released TransitionStub and TransitionGroupStub in 1.0.0-beta.2:

import { TransitionGroupStub, TransitionStub, shallow } from 'vue-tes-utils'

const wrapper = shallow(Component, {
  stubs: {
    'transition': TransitionStub,
    'transition-group': TransitionGroupStub
  }
})

[autumnwoodberry]

Awesome! I will check it out when I have some spare moments.

[petridw]

@eddyerburgh I'm using TransitionStub and attempting to assert that elements enter & leave the dom after data change (two elements with a simple v-if/v-else inside a <transition> tag). It seems to work on enter, but not on leaving - the content inside the <transition> tag remains in the wrapper's html and receives the v-leave and v-leave-active classes. I expected the transition stub to just cause inner content to instantly enter/leave, is that understanding off the mark?

[eddyerburgh]

Hi @petridw, leave hasn't been implemented. I'll look into it.

Do you have an example I could add as a test?

[petridw]

@eddyerburgh here's a failing test that should be passing, I think:

component-with-transition.vue

<template>
  <div>
    <transition>
      <div v-if="bool" key="a">{{ trueText }}</div>
      <div v-else key="b">{{ falseText }}</div>
    </transition>
  </div>
</template>

<script>
export default {
  name: "component-with-transition",
  data() {
    return {
      bool: true,
      trueText: "a",
      falseText: "b",
    };
  },
};
</script>

transition.spec.js

import { shallow, TransitionStub } from "vue-test-utils";
import ComponentWithTransition from "@/components/component-with-transition";

const options = {
  stubs: {
    transition: TransitionStub,
  },
};

describe("component-with-transition", () => {
  it("swaps dom nodes properly", () => {
    const wrapper = shallow(ComponentWithTransition, options);
    expect(wrapper.text()).toBe(wrapper.vm.trueText);
    wrapper.setData({ bool: false });
    expect(wrapper.text()).toBe(wrapper.vm.falseText);
  });
});

[eddyerburgh]

Thanks @petridw, if you remove the keys, the test passes.

The TransitionStub basically behaves the same as an unstubbed transition, except it doesn't add leave classes when the component inside is hidden, and it always returns the child synchronously.