Run & review this pull request in StackBlitz Codeflow.

Open in Stackblitz • bsvn-vite-ts

npm i https://pkg.pr.new/bootstrap-vue-next/bootstrap-vue-next@2596

npm i https://pkg.pr.new/bootstrap-vue-next/bootstrap-vue-next/@bootstrap-vue-next/nuxt@2596

commit: 03bda6f

@VividLemon, @xvaara a couple of questions about this

• I found myself going through convolutions to document the fact that the sortBy model contains a field for the custom comparer function. I understand moving the definition of the custom compare from being a global property on the table to something that is (or can be) field-specific. But why can't we put that on the field definition rather than the sortBy definition? Then we wouldn't have the wipe-out problem and I think the dev experience for single sort would be cleaner
• From my reading BSV used v-model in a kind of kludgy way to expose the rows that it's currently displaying. I don't think we should re-implement that, but it might be useful to expose computedDisplayItems - I think that would serve the same purpose and be considerably cleaner.
• When writing the stub description of the default compare, I just hand-waved over getStringValue - I wonder if it's worth exposing this somehow? Since were not adding all the bells and whistles to modify the default compare (allowing the user to specify locale and options), it seems like it would be worthwhile to make it easy to re-implement the default with different values and exposing getStringValue would be a key part of that.

Let me know what you think and I'd be happy to take on any of these if you agree that they're worth pursuing.

@VividLemon, @xvaara a couple of questions about this

• I found myself going through convolutions to document the fact that the sortBy model contains a field for the custom comparer function. I understand moving the definition of the custom compare from being a global property on the table to something that is (or can be) field-specific. But why can't we put that on the field definition rather than the sortBy definition? Then we wouldn't have the wipe-out problem and I think the dev experience for single sort would be cleaner
• From my reading BSV used v-model in a kind of kludgy way to expose the rows that it's currently displaying. I don't think we should re-implement that, but it might be useful to expose computedDisplayItems - I think that would serve the same purpose and be considerably cleaner.
• When writing the stub description of the default compare, I just hand-waved over getStringValue - I wonder if it's worth exposing this somehow? Since were not adding all the bells and whistles to modify the default compare (allowing the user to specify locale and options), it seems like it would be worthwhile to make it easy to re-implement the default with different values and exposing getStringValue would be a key part of that.

Let me know what you think and I'd be happy to take on any of these if you agree that they're worth pursuing.

Add this to a github issue for discussion