Weird interaction when working with 'react-sortable-hoc'

[FateRiddle]

https://codesandbox.io/s/qYEvQEl0

So I wrote a demo myself that didn't work compare to one sample that works, the only difference being one props for <List/>

rowHeight={({ index }) => 50}

rowHeight={50}

I use the latter way. And it is not working. Why?

[bvaughn]

This creates a new function prop each time you render:

rowHeight={({ index }) => 50}

That's sufficient to trigger a re-render of the child component, even if no other properties changed. In this case, you could pass a small attribute that changes each time sort order changes (eg an incremented counter) to let the component know to re-render.

Check out the section on "pure components" in the docs for more info.

[FateRiddle]

@bvaughn I have to do a lot more than sorting, all CRUD on items, I'm using redux, so the list of task can be read from redux store as array of tasks

[{id:12312, title:task1, completed:false, ... }, { ... }, ...]

I add state sortCount as you suggested, and making it props of <List />, so now sorting works.
But I can't afford adding a setState() in every action I made（some may not even change any state at all like arrow key result in cursor movement among <Row/>）, so I do it in componentWillReceiveProps

  state = { sortCount: 0 }

  componentWillReceiveProps(nextProps) {
    this.setState({ sortCount: this.state.sortCount + 1 })
  }

my question is, is this a burden for performance? How do I improve?

[bvaughn]

Any time your data changes, you need to re-render the list, right? There's no way around this.

You don't need to use a counter. Actually if you have something in the data that changes, it's probably even better to just pass it through (eg a prop like sortOrder or...anything).

I spent a lot of effort optimizing react-virtualized. Re-rendering isn't that expensive since it's only rendering a slice of the rows.