8000 docs:(BTable): Extend documentation and migration guide for sorting by dwgray · Pull Request #2596 · bootstrap-vue-next/bootstrap-vue-next · GitHub
[go: up one dir, main page]
Skip to content

docs:(BTable): Extend documentation and migration guide for sorting #2596

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
merged 1 commit into from
Mar 10, 2025
Merged

docs:(BTable): Extend documentation and migration guide for sorting #2596

merged 1 commit into from
Mar 10, 2025

Conversation

dwgray
Copy link
Member
@dwgray dwgray commented Mar 8, 2025 •
edited
Loading

Describe the PR

  • Attempt to clarify the use of sortBy model.
  • Add a deprecation warning to v-model binding section
  • Add documentation for sort compare functions
  • Updater migration guide

Small replication

A small replication or video walkthrough can help demonstrate the changes made. This is optional, but can help observe the intended changes. A mentioned issue that contains a replication also works.

PR checklist

What kind of change does this PR introduce? (check at least one)

  • Bugfix 🐛 - fix(...)
  • Feature - feat(...)
  • ARIA accessibility - fix(...)
  • Documentation update - docs(...)
  • Other (please describe)

The PR fulfills these requirements:

  • Pull request title and all commits follow the Conventional Commits convention or has an override in this pull request body This is very important, as the CHANGELOG is generated from these messages, and determines the next version type. Pull requests that do not follow conventional commits or do not have an override will be denied

@bolt-new-by-stackblitz Bolt.new (by StackBlitz)
Copy link

Review PR in StackBlitz Codeflow Run & review this pull request in StackBlitz Codeflow.

@pkg-pr-new pkg.pr.new
Copy link
pkg-pr-new bot commented Mar 8, 2025

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

@dwgray dwgray marked this pull request as ready for review March 8, 2025 18:50
@dwgray
Copy link
Member Author
dwgray commented Mar 8, 2025 •
edited
Loading

@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 VividLemon merged commit e5e6b21 into bootstrap-vue-next:main Mar 10, 2025
4 checks passed
@VividLemon
Copy link
Member

@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

@VividLemon VividLemon mentioned this pull request Mar 10, 2025
Open
@dwgray dwgray deleted the table-sort-docs branch April 22, 2025 16:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@VividLemon VividLemon VividLemon approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@dwgray @VividLemon
0