React-table: Ids for select table checkboxes

[dclark27]

Is your feature request related to a problem? Please describe.
Currently, the Select Table HOC does not have the ability to add IDs to the select all checkbox, nor the individual checkboxes that are generated. Automation team members of mine need these IDs to create automatic test suites for the front end.

Describe the solution you'd like
Add ID fields to checkbox props that I can pass to add IDs to the select all/individual checkboxes on the Select Table HOC.

Describe alternatives you've considered
Automatically add IDs based on the keyfield prop.

I am happy to create a PR for this issue.

[snehjogani]

@dclark27 is there a way to set another field from the data as ID for the checkboxes instead of the default _id?

[tannerlinsley]

I would accept a PR to add/update/fix this functionality, or you can wait for v7 (a month or two). Thanks for the input!

[igodorogea]

Previous PR #1208 breaks current solutions which are using keyField="id", because toggleSelection in 6.8.6 was sending one thing(the desired id) but now in 6.9.0 is sending select-#id

[ashkank83]

I'm experiencing the same issue as explained by @igodorogea . returned key in toggleSelection is select-#id now which I don't think is the correct behaviour. Any plans to fix this please?

[ggascoigne]

Why is this closed when it's clearly still broken?

[tannerlinsley]

I am no longer actively triaging or working on issues for v6. That doesn't mean someone can't submit a fix for this issue (which I will accept as long as it is non-breaking), but v7 will eliminate this class of issue entirely, so it's not on my immediate radar.

[ggascoigne]

I do understand this, I'd feel less frustrated if this hadn't been broken after you stopped actively working on v6. From my point of view the latest v6 has been broken for 6 months. Like several others, I'm still pinned to 6.8.6.

And like several others, I don't understand why the change was made in the first place, which makes submitting a PR to fix it rather awkward.

[tannerlinsley]

Trust me, I understand your frustration. The decision was not purely logical though. I would have loved to continue to support v6 indefinitely, but the amount of issues that were coming in every day vs the contributors I had working with me (1 or 2) and the time we had for the project were an extremely unhealthy ratio.

I decided that instead of spiraling out of control into oblivion on v6 and never making any progress, that I was ready to accept the consequences of capping v6 and starting on v7 regardless of the state of the project. Regardless, due to the way I built it in the first place and the API that it exposes, issues would have theoretically continued to pour in beyond capacity as usage or use-cases of the library grew.

As the for breakage, I totally agree. The simplest solution I see would be to issue a new release on the latest v6 tag for the 6.8.6 version. If you think this is perfectly fine, then I have no issue rewinding the master branch to that point and making a release.

[ggascoigne]

That makes a lot of sense, and I can only imagine how much work it is to maintain a popular open source library like this one.

I appreciate the offer of a new release but I have to assume that that will simply cause issues for anyone who wanted the behavior that got changed or the new minor tweaks that went into the 8.9.x versions. I do have a work around (pinning to v8.8.6), so maybe the best approach is to just leave it alone for now and stick to working on v7.