Keep $children order in sync with $slots order

[miljan-aleksic]

What problem does this feature solve?

The $children array does reflect the order of the rendered components, but if those are reordered, when using v-for for example, the order is not synced.

I would like to request this as for some advanced components would remove the need for tricky workarounds.

[yyx990803]

IMO this requires too much internal refactoring and potential complexity to cater to some niche use cases. Personally, I have yet to run into a case where I even need to use $children. Reaching for child component instances really is only meant for workarounds, not a recommended practice.

[miljan-aleksic]

Thanks Evan. The case I am facing with is a <table> fed with <table-columns>. Each column holds the rendering of the header in the default component render as well as the cellRender as a special function. The special function is retrieved by the table from the slots and rendered as part of the table template.

The above works great for simple functional data rendering, but not for more advanced features where cellRendering requires access to the column instance, to render a select column or trigger events for example.

Is there any smart way of doing this that I am missing?

[miljan-aleksic]

@yyx990803, I went finally using $slots directly as their provide enough information to render the cell directly. Although, for more advanced features still access to the column instance is necessary.

The slot object has the componentInstance attribute but at the moment of rendering it results to undefined. Is this a technical limitation?

Thank you for your time looking into this.

[miljan-aleksic]

Checking this further, at the moment of the table rendering, the childs haven't yet been inited while the cells are being rendered, meaning there is no instance to associate with. I opted for a simple workaround assigning $children to table local data forcing it to rerender but this time the instances are available and I can "try" to find the right instance.

I say try because there is no easy way, that I know about, to associate the slot with the instance. So far I am using the node tag and the props to do so.

[CaelanStewart]

@yyx990803, I've run into a situation where this is very useful. For instance, I'm currently writing a component that will enable the layout of a list of items with a non-constant order into columns, with different layout modes for different purposes. I can't use flexbox for this purpose due to browser compatibility.

<column-layout :columns="2">
    <column-layout-item v-for="(item, index) in items" :key="index">
        // html
    </column-layout-item>
    ...
</column-layout>

In cases like the above, with my knowledge of Vue, there is no way that from within <column-layout>, I can get the children in their rendered order without explicitly letting the component know about the items. But I'd like for the parent component to be able to act without that knowledge.

Yes, it is a bit of an edge case, but I've found a few people who've had such problems in my Google searching that led me to this thread.

[nblackburn]

Why not create a event emitter for the components in question to tackle this problem.

[CaelanStewart]

@nblackburn

Well, that'd be because the content of <column-layout> is passed down via a slot, therefore I cannot listen to events emitted from instances of <column-layout-item> via the slot.

I'd have to do this from within the <column-layout-item> component:

this.$parent.$emit('item-mounted', this)

Which I guess is, fine, but it doesn't solve the problem.

The source items array that <column-layout> is displaying has a corresponding set of fields in a sidebar that allow deletion, addition and re-ordering of said items. If I add an item, and then re-order it, the ordering is lost again.

I know how I can fix this, it just means passing the original array of items to the <column-layout>, such that it may maintain it's own internal map of items to child components that is in the correct order.

It's just a little cleaner if the $children maintains the correct order. And plus, I want this component to work in places where content is not dynamic, where I have no array of items. So if I make the prop optional, this increases the chances that a developer will forget to pass the array of items. And in my use case, it's being used for a document template editing system, in such a way that this component will be used many times in a single template, as such it would - if forgotten - introduce a bug that may easily escape testing.

I just can't help but feel like it doesn't make sense that the $children array would not reflect the actual order of the components.

It kind of feels like something an old version Internet Explorer would do to the childNodes property of an element.

[CaelanStewart]

And, plus this comment from @yyx990803 says himself that in the example provided by the OP of that thread, the components are coupled by design, and he suggests emitting events up to the parent via $parent.

So to advocate the use of $parent, but to advise against using $children feels a little inconsistent.

To add, I do understand that development isn't straightforward, and that this change may incur a fair deal of work. I just wanted to add my two cents, in the name of consistency for the sake of consistency.

[nblackburn]

@CaelanStewart I don't mean that, allow me to demonstate...

Create a file that will house an event bus...

import Vue from 'vue';

let eventBus = new Vue();

export default eventBus;

then you import the eventBus into the components that you want to communicate across.

import '../eventBus.js';

And emit the event when the comonent is created/mounted and before it is destroyed.

created () {
    eventBus.$emit('column.add', this);
}

beforeDestroy () {
    eventBus.$emit('column.remove', this);
}

From there you can simply handle the event in the parent component like so...

created () {
    eventBus.$on('column.add', this.handleColumnAdd);
    eventBus.$on('column.remove', this.handleColumnRemove);
}

This will give you the instance, is independent of other components and allows you to track the order in which they are mounted and only works where you have added it.

[CaelanStewart]

@nblackburn

That does't allow me to track when items are reordered, though. The mounted and destroyed hooks of the items are not called a second time when you move an element in an array from one index to another.

Take a look at this JSFiddle for demonstration. See the initial array of items in the root Vue component. In the root Vue components mounted hook, I simulate a user re-ordering the items after 2000ms, after the components have already mounted. Take a look at the console, the mounted hooks fire once on initial instantiation of the <item> components. And then after two seconds, when the items have been re-ordered, you'll see that only the updated hooks are then fired on the <item> components. Now, the problem is, I have no idea what the new index of the items are from inside the updated hook, because no such information is passed as an argument.

And plus, in response to your suggestion about an event bus, If I use an event bus, and I use multiple instances of <column-layout>, that's not going to work. I'll have to compare the parent component to check that it is indeed a child of the parent, and not the child of another instance.

Would it not be better to use this from the child component, which I have done in the JS fiddle:

this.$parent.$emit('item-mounted', this)

[CaelanStewart]

Anyway, regardless of what I can do to fix it, as I said in a previous comment, I already have a solution, but it's not ideal. My point is that we're having to introduce all this faff to be able to track the re-ordering of components, and get an array of the components in the correct order.

I just wanted to add my 2 cents, as this problem introduces an inconsistency, and one that seems not very Vue like, to me at least.

Who knows, if enough people end up agreeing maybe it'll happen?

[nblackburn]

@CaelanStewart I never suggested it as a direct answer, just a decoupled way of parent-child communication which could be applied to get you closer to something that works for you.

If this has become an hurdle, try to think about the issue in a different way because i don't think this is a problem for Vue to solve.

[CaelanStewart]

@nblackburn, okay, fair enough. I was a bit confused as to why you were suggesting something that isn't fit for my case.

[CaelanStewart]

Amongst my huff, adding my two (or 10, retrospectively) cents, I neglected to properly read other responses to this thread. I see that @miljan-aleksic used $slots as a solution, this indeed does work and I now have access to the child components in the correct order.