KeyField enhancement suggestion

[waynebrantley]

• Sometimes the data that comes back from the server has no suitable key. KeyField auto increment #166 (Like data from several different sources in one result, etc). the table requires a keyField. So, what happens is I create an extra field in my object, do a map operation on it to set the keyFields to a simple rowIndex number:

data.map((val, ix) => {
                            val.id = ix
                            return val
                        }),

• Sometimes the data that comes back from the server has a key that is calculated from several other columns (composite key). Implement Multiple columns as keys #113 Again, this can be solved in the same was as the above - but instead of using the rowIndex, you calculate the key:

data.map((val, ix) => {
                            val.id = val.field1+value.field2
                            return val
                        }),

I would like to propose a better solution to the above.

• Add a isKeyField:boolean to the column definitions. The table would then call the existing column.formatter function (if provided or use ``dataField) to calculate the key. With that code the developer could easily build a composite key or use something like https://www.npmjs.com/package/shortid Two columns have same dataField will cause the same key warning of React #601

The other part of this solution is the automatic numbering. Since the formatter function receives a rowIndex as a parameter, it could simply return this number.

Currently the table requires keyField property to be populated. The above implementation would imply that it would require keyField or a column isKeyField=true. However, I think it would would be a good feature of the table that if there is no keyField set on the table..and no isKeyField column, that the rowIndex would be used as a default implementation.

I think this solves all the referenced tickets and seems like it would be a fairly easy implementation? If this isKeyField existed, I would personally always use that instead of the keyField property...possibly you could consider deprecating the keyField property on the table in favor of the much more flexible column definition.

[AllenFang]

@waynebrantley thanks for your proposal, yeah, currently, I am also want to enhance the key mechanism in table. I think generate automatic increase number is much easier solution so far.

however, i have a question about:

• Add a isKeyField:boolean to the column definitions. The table would then call the existing column.formatter function (if provided or use ``dataField) to calculate the key.

Can you explain it more? You mean if this table have three columns, and I call all of the column.formatter then combine the result of them as the row key?

[waynebrantley]

@AllenFang What I am saying is there will only be one column defined with isKeyField=true. So, you locate a column with that setting and that will be the column you call the column formatter to get the key. You will call the same code you normally do - for example, the column may not have a formatter and will just have a dataField - so you would use that....same logic you use when getting what to display for a column will be used when getting what the key is. If no column is defined with isKeyField=true you would use automatic increase.

[AllenFang]

@waynebrantley I see. however, I think there're few side effect:

• if there're same result of column.formatter, we will in trouble and It did happen, but I think developer know that and hopefully they will not add isKeyField in a non-unique column lol

• sometime, the result from column.formatter is not like a simple string, it's can a react element or a complex dom structure.

This can be a good idea when developer keep the result of column.formatter more simple.

[waynebrantley]

@AllenFang for your side effects

• yes, agree the developer is responsible to see that the key column yields a unique value. No different than today.
• yes, agree normally a formatter can return anything, but in the case of a key - it should return a simple string.

I think these will be great improvements to your awesome component!

[AllenFang]

Cool, I will consider these suggestion more then find some time to implement it! Thanks so much 👍 @waynebrantley

[sunshineo]

I'm coming from a different angle to suggest that have keyField to be optional and use rowIndex as default value. I setup my table and later added react-bootstrap-table2-editor . But the first column (keyField) cannot be edited. It was not obvious at all on why. Until after a lot of google and then I'm facing the same problem. I have to add row index as keyfield.

[AllenFang]

#218

[senthilmca90]

@AllenFang Any update on this one?

[jordan1982]

@AllenFang Any updates on this? I'm really interested in this update, could you tell me when you'll implement this feature? Or you can suggest me how to use the bootstrap table with a composite key?

[turkus]

Following by #166 I'm also interested in an update, but... we did a lil' bit workaround for this until this issue would be solved.

Our case was just to enumerate ordinal number as a first column in a table. We let a react boostrap table to be independent component, and put it into our wrapper component called Table and by combining useEffectLayout when some events happens (in our specific case sort, so new props provided) we solved that problem.
First we made a first column with a specific class name and leave it empty ('') in every row. Then in useEffectLayout we used an old school way to get this done, by html class selector to get all occurencies and by iteration we put there ordinal number by innerHTML. Works like a charm, without the flashing content.
It's not a brilliant solution, but until you won't get you want, you can take a chance to use it.

Hope that helps!

[waynebrantley]

@AllenFang Any consideration to implementing this feature?

[khanh-nguyen]

Another vote for this issue.
I'd love to have keyField being optional. I want to use react-bootstrap-table to render my data, so I don't want to alter my data by adding a unique key to it. There are many cases where uniqueness is not required in data.

Thanks,