feat: add the form_action property to manually trigger form actions
#98
Conversation
🦋 Changeset detectedLatest commit: 8e121ce The changes in this PR will be included in the next version bump. Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Summary of Changes
Hello @Col0ring, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!
This pull request enhances the Form component by providing a new mechanism to control form behavior programmatically. It allows developers to trigger form actions such as submission, validation, or resetting fields directly through a dedicated property, offering greater flexibility in managing form states and interactions.
Highlights
- New form_action property: Introduces a
form_actionproperty to theFormcomponent, enabling programmatic triggering of form actions likereset,submit, andvalidate. - Automatic Reset: The
form_actionproperty automatically resets its value after an action is triggered, allowing for multiple subsequent calls. - Enhanced Documentation and Demos: Adds new demo files (
dynamic_form.py,form_action.py) and updates documentation in both English and Chinese to illustrate the usage of the newform_actionproperty and dynamic forms.
Using Gemini Code Assist
The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.
Invoking Gemini
You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.
| Feature | Command | Description |
|---|---|---|
| Code Review | /gemini review |
Performs a code review for the current pull request in its current state. |
| Pull Request Summary | /gemini summary |
Provides a summary of the current pull request in its current state. |
| Comment | @gemini-code-assist | Responds in comments when explicitly tagged, both in issue comments and review comments. |
| Help | /gemini help |
Displays a list of available commands. |
Customization
To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.
Limitations & Feedback
Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.
You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.
Footnotes
-
Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩
There was a problem hiding this comment.
Code Review
This pull request introduces a form_action property to manually trigger form actions, which is a useful feature. The implementation across the backend and frontend is solid. I've identified a couple of areas for improvement: a minor refactoring in the frontend for better code clarity and robustness, and a logic bug in the custom validator within one of the new demo files. I've provided specific suggestions to address these points.
| """(rule, value, cb) => { | ||
| if (value !== '123') { | ||
| cb('Password must be "123"') | ||
| } | ||
| cb() | ||
| }""" |
There was a problem hiding this comment.
The custom validator logic is incorrect. The callback cb is called unconditionally at the end, which will likely cause the validation to always pass, regardless of the input value. The cb() call should only be made once per validation path. Using return ensures the function exits after calling the callback, which is a robust pattern for this kind of validator.
| """(rule, value, cb) => { | |
| if (value !== '123') { | |
| cb('Password must be "123"') | |
| } | |
| cb() | |
| }""" | |
| """(rule, value, cb) => { | |
| if (value !== '123') { | |
| return cb('Password must be "123"'); | |
| } | |
| return cb(); | |
| }""" |
| useEffect(() => { | ||
| switch (formAction) { | ||
| case 'reset': | ||
| form.resetFields(); | ||
| break; | ||
| case 'submit': | ||
| form.submit(); | ||
| break; | ||
| case 'validate': | ||
| form.validateFields(); | ||
| break; | ||
| } | ||
| onResetFormActionMemoized(); | ||
| }, [form, formAction, onResetFormActionMemoized]); |
There was a problem hiding this comment.
For clarity and to prevent unintended side effects, it's better to add a guard clause to ensure that onResetFormActionMemoized is only called when an action is actually performed. This makes the code's intent clearer and more robust.
useEffect(() => {
if (!formAction) {
return;
}
switch (formAction) {
case 'reset':
form.resetFields();
break;
case 'submit':
form.submit();
break;
case 'validate':
form.validateFields();
break;
}
onResetFormActionMemoized();
}, [form, formAction, onResetFormActionMemoized]);
|
@Col0ring Thank you very much. I can now use this to implement parent-child forms. |
No description provided.