-
Notifications
You must be signed in to change notification settings - Fork 14.5k
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
Migrate trigger form params to new UI #45270
base: main
Are you sure you want to change the base?
Migrate trigger form params to new UI #45270
Conversation
51d3c4d
to
83c450e
Compare
Thanks @jscheffl for working on this. As mentioned in TODO, we will support the accordion and not flat. Some points which i noticed, just writing it down incase we don't miss.
Overall this is going in right direction. Should we have inbuilt scroll for the dynamic form? since the modal seems very long. EDIT: Just saw a todo for point 6 (json code view) and most of the above issues as todo. |
e7381e7
to
8067918
Compare
(1) I recommend to make into a separate PR - as also discussed 1:1 So... for the Layout part I'd say... ready for review! |
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.
Thanks @jscheffl ! Overall it looks good. Just few comments.
When clicking on trigger run, the modal pops up with all the options at front.
Should we consider them in a accordion and if needed user can view?
Apart from it, had some general comments, which is similar for all files.
airflow/ui/src/components/FlexibleForm/FlexibleFormFieldAdvancedArray.tsx
Outdated
Show resolved
Hide resolved
airflow/ui/src/components/FlexibleForm/FlexibleFormFieldBool.tsx
Outdated
Show resolved
Hide resolved
|
||
export const FlexibleFormFieldDate = ({ name, param }: FlexibleFormElementProps) => ( | ||
<Input | ||
defaultValue={param.value as string} |
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.
Should we check the type of param.value or it will be for sure string?
If No, we should consider using typeof param.value === "string" ? param.value : "";
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.
Added a bit of safety net in all default parameters taking this from param.value
- can you take a look again?
…o separate TSX file
8067918
to
313d868
Compare
After @shubhamraj-git has added the trigger form to the new React UI, this PR now adds the flexible trigger form - Based on the logic of the former AIP-50 implementation - using DAG ParamsDict to render form fields based on field definitions.
Note that the form rendering was made as a component by intent as it will be re-used in Connection Forms in future to render connection extra fields.
To test the form rendering the following DAGs might be good candidates:
example_bash_decorator
- has no params so should not display a specific formexample_bash_operator
- has one basic parameter w/o any special thing. Simple as it can beexample_params_trigger_ui
- has 4 parameters, still basic... and with advanced section un-folded:
example_params_ui_tutorial
- this is the most complex beast as it has all features as a demo that shall be supported....and the lower section un-folded:
Scope of the PR is the UI layout and logic to render. What is missing and will be a follow-up PR is the binding and sync of the form field content with the JSON dict that is used to trigger the DAG in the "Advanced Options" section.