So I think there's been some discussion on this in the past. I'm in favor of complying with the existing BS4 events emitted by the modal:

It is important to note that this can't be done with just calling these events in a different order—transition-group hooks have to be implemented. An added difficulty bonus here is that the transition group hooks are called once per transition element. We currently have two transition elements.

Well, I'll just add BS4 event system there

Also, Vue.js (and boostrap-vue) is reactive based, whereas Bootstrap V4 native is event based. so there are a few differences in how things can be handled.

Although I do think having some of the added events fire on $root would be handy... The biggest issue is providing context to the event when it is fired. i.e. providing the ID of the component, a reference to the component, or an event object (with target and maybe relatedTarget attached).

@youaresofunny You can see part of the long-running questions on issue #276

Yep, but this commit is not about $root emits 🚶‍♂️

You're right, @youaresofunny , I got carried away on another topic. The order of events seems more sensible with your changes. They don't take into account the asynchronous nature of the transitions, but that is probably best dealt with in a later, breaking change. Now with your event renaming, I don't believe we've made any breaking changes at all, and you should have your event flow worked out.

Any extra thoughts, @tmorehouse ?

I wonder if we should standardize the format / calling signature of all component emits on $root?

i.e. this or something like this:

this.$root.$emit('event::name', this.id, this, other, args, here)

this.$root.$on('event::name', id, ctx, other , args, here)

Although not all components have an id, so maybe just this and the receiving handler could look for a ctx.id?

For local vm.$emits() I don't see too much of an issue with the proposed order.

the transition triggered events might be something we have to deal with later.

@tmorehouse, with all those options, why not make a class and just pass that? I've got some sweet class patterns you guys might like, so pass me the prop names and I'll PR the internal event object so we can define an interface and avoid too many parameters.

The modal click handler (where it can be canceled) is kind of nifty, although it is binding to a native event structure ($event) which we don't have the luxury of in $emits. So maybe modeling after the native event might be handy, or we could just create an event from new Event and take advantage of that. although it might have too many props we don't need.

I can see possibly providing 'target' being the VM of the component, and relatedTarget could be a reference, if needed to, another element.

Maybe event.target (native element ref), event.$target being the component VM reference, etc.

Yeah, I was thinking of more of a hybrid event. A class that uses a lot of the same Event names, but it more scoped to the internal needs of the BV components. For example, the emitting component would be placed on target, and the modal canceler would be done with a closure trick using a preventDefault callback on the SyntheticEvent.

If you've played with react, they have done some cool things with their synthetic event to make it familiar, but ergonomic. We have very small needs, but I thought that was a good target to emulate.

Cool. I think it should have props similar to cancellable and defaultPrevented, etc.

relatedTarget, could be good as well (and optionally set, null otherwise)