-
-
Notifications
You must be signed in to change notification settings - Fork 157
feat(input fields): expose method onBlur to be able to manually stop debouncing (draft) #2758
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
base: main
Are you sure you want to change the base?
Conversation
|
WalkthroughThis change updates the Changes
Possibly related PRs
Suggested reviewers
Poem
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
commit: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🧹 Nitpick comments (1)
packages/bootstrap-vue-next/src/components/BFormInput/BFormInput.vue (1)
104-104
: Implementation looks correct but consider potential side effects.The approach of exposing
onBlur
asflushDebounce
aligns well with the PR objective of manually flushing debounced input values. Blur events typically handle flushing pending debounced operations, which should resolve the form submission issue described in the PR.However, consider that calling
flushDebounce()
will execute the full blur handler, which may have side effects beyond just flushing the debounce (such as emitting blur events, validation updates, or focus state changes). This might be acceptable for the intended use case, but users should be aware of this behavior.Consider adding a JSDoc comment to document this exposed method:
defineExpose({ blur, element: input, + /** Manually flush any pending debounced input by triggering blur logic */ flushDebounce: onBlur, focus, })
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
packages/bootstrap-vue-next/src/components/BFormInput/BFormInput.vue
(1 hunks)packages/bootstrap-vue-next/src/components/BFormTextarea/BFormTextarea.vue
(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (1)
- GitHub Check: build
🔇 Additional comments (1)
packages/bootstrap-vue-next/src/components/BFormTextarea/BFormTextarea.vue (1)
117-117
: Consistent implementation with BFormInput - looks good.The implementation mirrors the approach used in
BFormInput
, maintaining consistency across form input components. This ensures developers have a unified API for flushing debounced values across different input types.
Now that issue #2721 has been merged, I've been thinking about situations where it would be useful to be able to manually stop debouncing (while editing a field's contents).
Let's say we're using a b-form-input field with a high debounce value (e.g. 2 seconds, to make it easier to observe the issue) and we want to be able to submit a form by pressing Enter in that active field.
In this case, the value sent by the form might be incomplete due to the debounce delay on the field's model value.
Small replication
You can observe the problem in this demo.
The simplest fix is to expose the "onBlur" method (calling it "flushDebounce" for example) and add the following code to the b-form-input field:
You can try the fix in this demo (using a patched version of bootstrap-vue-next).
I'm leaving this issue as a draft for now, as I'm not sure if my patch is the ideal solution to this type of problem. Any suggestions are welcome.
PR checklist
What kind of change does this PR introduce? (check at least one)
fix(...)
feat(...)
fix(...)
docs(...)
The PR fulfills these requirements:
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 deniedSummary by CodeRabbit