Skip to content
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.

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

PR 2600 redraws entire table introducing performance and usability issues #3367

Closed
coreyshuman opened this issue Feb 20, 2025 · 1 comment
Closed
Labels
bug Something isn't working

Comments

@coreyshuman
Copy link

coreyshuman commented Feb 20, 2025

Environment

  • Operating System: Windows_NT
  • Node Version: v20.11.1
  • Nuxt Version: 3.15.4
  • CLI Version: 3.22.1
  • Nitro Version: 2.10.4
  • Package Manager: [email protected]
  • Builder: -
  • User Config: devtools, modules, compatibilityDate
  • Runtime Modules: @nuxt/[email protected]
  • Build Modules: -

Version

v2.20.0 and later

Reproduction

I could not get Stackblitz to work when changing Nuxt UI versions due to internal 503 errors. Please forgive me for using codesandbox instead.

Nuxt UI v2.19.1 - Working as expected. You can edit and tab between inputs.
https://codesandbox.io/p/devbox/nuxt-v2-19-1-lz5zvk

Nuxt UI v2.20.0 - Cursor position lost when typing. Second column (email) uses .lazy which allows typing but loses focus when tabbing after edit.
https://codesandbox.io/p/devbox/nuxt-v2-20-0-x9xylj

Description

Release v2.20.0 includes PR #2600 which redraws every table column slot on any changes to the table source data. This introduces significant performance impact on large tables and makes it difficult for users to interact with inputs within tables since the redraw will lose cursor position. This also makes it impossible to tab between columns when data changes.

I intend to submit a PR which reverts the changes made in #2600.

Additional context

I demonstrate in #2004 (comment) that the issue reported which prompted PR #2006 was a misunderstanding and was not related to table behavior at all. Therefore, that PR is unnecessary and does not directly address the issue, yet it introduces unintended side effects.

@dustin-we
Copy link

Thank you for helping me find this issue, I was wondering what caused this

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants