Subcomponent refers to different row value when the data changes/re-sorts about table HOT 7 CLOSED

Let's talk though some of this:

1. I am pretty sure that as long as you don't pass the table any sorting information, it won't sort at all. I'm not totally sure how you would go about returning to this non-sorted state after choosing to sort by a column.
2. When you say the data is changing, are you referring to the sub-data or overall data changing. It seems that if you updated the main data in any way that affected the number of results, order, or pagination, you would end up seeing a completely different row's sub-component. This would lead me to the next question...
3. Would it be expected that when the data model changes in any way that every expansion level is collapsed? This would be very easy to do, and treats each dataset as it's own "session" in a way. I know that right now, everything is collapsed on page change. This way, it seems normal to do the same with data changes. Thoughts?
4. It seems that even if it proved to be a large enough use case, it will be extremely difficult to get away from sorting running when new data is fed to the table. Otherwise, the you would have to fire the sorting yourself. In my opinion, I think I am leaning more towards item 2.

Let me know what you think

from table.

Wow thanks for the quick response.

1. Yes, this is correct- when Sortable is false, the table doesn't auto-sort, which is great, but there's no way to set the column state back to no-auto-sort after choosing to sort by a column. Wonder if a way to turn off and resume the sorting functionality would be valuable?
2. When the main data changes, the rows will re-sort. In my case, I have rows of users: first name, last name, username, and other information. If someone changes their username or a new user signs up, the table of users will either re-sort or insert the new user. When a sub-component is open, then yes I do end up seeing a completely different row's sub-component data. (ex: I have users Anna, Charlie, and Doug. I have Charlie's sub-component open. If a user Brad signs up while the sub-component is open, the sub-component will instantly switch to Brad's information without any user input)
3. I think closing the sub-component is one way to do it (is there a to trigger all expansions to close?). My use-case though is that I have user information and form elements in the sub-component (this is a moderator view where mods can change and add other user info), so if a moderator is currently reading about or modifying a user's information and the data changes somewhat frequently or unexpectedly, then moderators would have a very difficult time viewing that interface, because the sub-component will keep closing while they're using it. The other use-case is that moderators can save/update a user's information- if the mod changes a user's first name and saves it, the row will also re-sort and the sub-component will immediately display another user's information. In this case, it would also be nice if sorting would be momentarily frozen, in case there was other information a moderator wanted to go over under the same user.
4. Yeah I think the problem is in the reactive nature (I'm using React+Meteor) so as soon as there is new data, the table shifts around. Having a manual sort mechanism (or a way to turn sort off completely) would actually be interesting- we only fire the sort manually regardless of the data; new data will be inserted to the end of the list, and all the rows will stay where they are. As soon as sort is turned back on, we can start sorting again. Though you're right, this use case might be fairly small.

Actually, I just thought of a way around this- if I could programmatically set which column to sort by, I could set the table to sort by a hidden, empty column to prevent the table from sorting. Getting the table to sort again would be as simple as letting it sort by any other visible column

from table.

I like your approach to the sorting. Remember that you can control the sorting model directly by passing sorting={[{id: COLUMN_ID, desc: true}]} as a prop. It's much easier There is also a corresponding onSortingChange callback that you can use as well. It's all in the "Fully Controlled Component" section of the docs. As for what we discussed, I think the way to go is to increase the api for row expansion.

from table.

If you would like to submit a PR to close the expanded rows on data change, I would merge or for you.

from table.

ok cool, I think I got the gist of it. I got sorting={this.state.sortArray} and I wrote a simpler sorting method in onSortingChange to handle my sortArray prop accordingly. That all works fairly well.
I also have expandedRows controlled by {this.state.expandedRow} as I'm now only allowing a single row to expand at a time, and a this.state.expanded flag that if true, prevents the sorting function from re-sorting.

I'm running into a very strange problem though- when I set the state's sortArray to different values, the ReactTable's classes all update with the correct ascending and descending styles, but the table doesn't actually sort (I think it doesn't trigger a re-render) until I either expand a column or click on the column to re-sort again, then it'll actually trigger the sorting re-render.

I got around this in a very hacky way by setting this.state.sortArray twice... with a delay... which I know is a pretty terrible way to write code.

if(this.state.sortingArray[0].asc) { this.setState({sortingArray: [{id:'firstName',asc:false}]}); _.delay(()=>{this.setState({sortingArray: [{id:'firstName',asc:false}]});}, 200); } else { this.setState({sortingArray: [{id:'firstName',asc:true}]}); _.delay(()=>{this.setState({sortingArray: [{id:'firstName',asc:true}]});}, 200); }

But nothing else really works... this is inelegant but it does. Do you have any ideas why this is happening?

Sure, I can add a closeRowOnDataChange={true} prop that closes optionally

from table.

I would just default the closeRowOnDataChange prop to true in the default props as I think this is expected functionality for a majority of use cases.

As for the strange behavior, I think we just need to make sure that we are firing off the sorting method when and if the sorting props change.

from table.

Fixed with the options provided in 1e4f838

from table.