Conversation
…o '/node-load-method/agentAgentflow'
Summary of ChangesHello, 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 significantly enhances the Agentflow node editor by introducing robust asynchronous input handling capabilities. It allows node parameters to dynamically fetch options from the backend API, improving user experience for fields like model selection or tool configuration. The changes involve new UI components, a dedicated data-fetching hook, and updates to API interactions, ensuring a more flexible and maintainable system for managing complex node inputs. Highlights
Changelog
Using Gemini Code AssistThe 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 by creating a comment using either
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 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
|
There was a problem hiding this comment.
Code Review
This pull request introduces asynchronous option handling for node inputs, a significant and well-executed feature. The use of a new useAsyncOptions hook and dependency injection for the AsyncInput component is a clean architectural choice that keeps UI atoms decoupled from data-fetching logic. The changes are comprehensive, including fixes for API endpoints, a bug fix for URL encoding, and extensive test coverage for the new functionality. The code quality is high, with good use of TypeScript and React best practices. I have one minor suggestion for improving the robustness of value parsing in the AsyncMultiOptionsInput component.
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
| * Get credentials filtered by one or more component credential names. | ||
| */ | ||
| getCredentialsByName: async (credentialName: string): Promise<Credential[]> => { | ||
| getCredentialsByName: async (credentialName: string | string[]): Promise<Credential[]> => { |
There was a problem hiding this comment.
does the API accept both single credential and credential array?
| /** Props passed to an async input component (asyncOptions / asyncMultiOptions). */ | ||
| export interface AsyncInputProps { | ||
| inputParam: InputParam | ||
| value: unknown |
There was a problem hiding this comment.
is it possible to define what the value type should be?
| if (error) { | ||
| return ( | ||
| <Box sx={{ mt: 1, display: 'flex', alignItems: 'center', gap: 1 }}> | ||
| <Typography variant='caption' color='error' sx={{ flexGrow: 1 }}> |
There was a problem hiding this comment.
this error display seems to be the same as the one used in AsyncMultiOptionsInput (line 106-108). Shall we extract to a small shared component to reduce duplication?
|
|
||
| function AsyncOptionsInput({ inputParam, value, disabled, onChange, nodeName, inputValues }: AsyncInputProps) { | ||
| const params = | ||
| nodeName || inputValues ? { ...(nodeName ? { nodeName } : {}), ...(inputValues ? { inputs: inputValues } : {}) } : undefined |
There was a problem hiding this comment.
Duplicated params construction — Both AsyncOptionsInput (line 12-13) and AsyncMultiOptionsInput (line 95-96) build params identically. Extract this to AsyncInput and pass it down, or compute it once in the dispatcher?
| * Get input argument names for the currently selected tool. | ||
| * Passes current node inputs as `currentNode.inputs` so the server can resolve the selected tool. | ||
| */ | ||
| getToolInputArgs: async (inputs: Record<string, unknown>, nodeName = 'toolAgentflow'): Promise<Tool[]> => { |
There was a problem hiding this comment.
nit: Tool seems to be an alias for NodeOption, which the shape is correct — getToolInputArgs returns objects with label, name, etc., which fits NodeOption/Tool exactly. The naming is slightly misleading since "Tool" suggests a tool, not a tool's input arguments
| isOptionEqualToValue={(o, v) => o.name === v.name} | ||
| onChange={(_e, selection) => { | ||
| const names = selection.map((s) => s.name) | ||
| onChange(names.length > 0 ? JSON.stringify(names) : '') |
There was a problem hiding this comment.
JSON string storage for multi-select values — AsyncMultiOptionsInput stores values as JSON.stringify(names). The validation layer and the component itself both need to parse this back. This works but creates a coupling that could be error-prone for future consumers. Worth a comment in the type definition for InputParam documenting this convention?
| * | ||
| * ### Built-in entries | ||
| * - `listChatModels` — fetches available chat models via `GET /assistants/components/chatmodels` | ||
| * - `listModels` — fetches available chat models via `GET /assistants/components/chatmodels` |
There was a problem hiding this comment.
nit, looks like the api has been changed to use POST instead?
getChatModels: async (): Promise<ChatModel[]> => {
const response = await client.post('/node-load-method/agentAgentflow', { loadMethod: 'listModels' })
...
}
jocelynlin-wd
left a comment
There was a problem hiding this comment.
no-blockers, feel free to review the comments in a follow up PR instead
JIRA - FLOWISE-228
Recording.mov