React-sortable-hoc: index is undefined in SortableElement v 0.4.10

[tecnoloco]

Hello, I updated to version 0.4.10 and now when I try to access index prop inside my SortableElement it is undefined, in the meantime I will return to previous version where everything is fine.

const SortableItem = SortableElement((props) => {
    const {name, fields, index} = props;

    if(fields.get(index).type == 'error'){
        return(
            <div className="file-upload-file-container file-container-error">
                {fields.get(index).file.name}
            </div>
        )

    } else{
        return (
            <div className="file-upload-file-container">
                {fields.get(index).file.name}
            </div>
        )
    }

});


const SortableList=SortableContainer(({fields, onDeleteItem})=>{
    return (
        <div className="">
            {fields.map((name, index, fields) => {
                return(
                    <SortableItem
                        key={`item-${index}`}
                        name={name}
                        index={index}
                        fields={fields}
                        >
                    </SortableItem>
                )
            })}
        </div>
    )
})

[williamkhshea]

It looks like index is explicitly omitted in SortableElement. What is the best way to access index if I really need it?

[clauderic]

Indeed, that's an unfortunate side-effect of https://github.com/clauderic/react-sortable-hoc/pull/100, which I've also run into myself a few times now.

For the moment, I've been dealing with it by passing down a different prop name like i={index}, but I realize that's not ideal.

I'm not sure what the best way to go about this problem is at the moment, though I'm absolutely open to suggestions if you have ideas on the matter!

[Robinfr]

Why not just stop omitting index?

[stahlmanDesign]

I'm glad to find this thread because I couldn't figure out this bug. I am doing what @clauderic suggested, passing index as prop (which is undefined but component issues warning if you don't include it) and also under another name like indexTemp which I then assign to index in the child component.

index={ i }
indexTemp={ i }

in child component:

index={indexTemp}

[derwaldgeist]

Came across this thread because I was wondering why the index isn't passed to the element. IMHO, this is quite important. In my use-case, each list item contains a "delete" button that enables the user to remove the item from the list. For this, I have to know in which item the delete button has been clicked. I'm already passing a key and an index, but both are "swallowed". Adding yet another index prop just seems to be overkill.

[mistercoffee66]

• 1

Could you update the docs to reflect this until/unless it's resolved? :^D

[dmiller9911]

@clauderic What are your thoughts on a forwardProps option. on the HOC's? This would be similar in function to Glamorous's forwardProps: https://glamorous.rocks/api#glamorous-api (no anchor for the API. It is a short scroll from the top). Usage would look something like this:

const SortableItem = SortableElement((props) => {
    const {name, fields, index} = props;
  ...
}, {
  forwardProps: ['index']
});

This.would be a pretty simple change that should meet the requirements for all issues related to this.

Another option would be to make a filterProps options that is a function that returns the props the component will desire.

const SortableItem = SortableElement((props) => {
    const {name, fields, index} = props;
  ...
}, {
  filterProps: ({ index, fields, name }) => ({  index, fields, name })
});

This would give somewhat more versatility, but could impact performance since it is ran every render, and requires more effort.

Both could also be implemented together, but one would need to run first, and documenting that could be difficult.

Let me know what you think. I would be happy to open a PR.

[supernintendo]

Why was this closed? This is some pretty janky behavior that at the very least should be documented. Thought I was going crazy until I realized it's a bug in this library. Ended up taking your suggestion @clauderic of passing the index as a separate prop.

[mguidetti]

I also ran into this problem and was very confused until finding this issue. I've implemented the work around of passing the index as an additional separate prop, but I agree with others that this feels unintuitive maybe not the best behavior.

[byr-gdp]

Is there anything update about this?
For getting index variable and pass unique key I have to use index and i together.