Factor out integration code from example to library, so that client apps can use it and it is test covered here.#435
Conversation
There was a problem hiding this comment.
Code Review
This pull request does a great job of refactoring the backend integration logic out of the example application and into the flutter_genui library. This significantly improves modularity, reusability, and testability. The new helper functions and data models are well-designed. My review focuses on a critical issue of an accidentally committed log file with sensitive data, along with several suggestions to improve code robustness, consistency, and testing practices.
…utils.dart Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
| }) async { | ||
| final techPrompt = genUiTechPrompt([_toolName]); | ||
|
|
||
| final toolCall = await Backend.sendRequest( |
There was a problem hiding this comment.
Shouldn't the backend be initiating these tool calls? Shouldn't it be something like:
- On startup, flutter sends tool declarations and system prompt fragment to the backend
- Backend does inferences whenever it wants and sends Gen UI messages back to Flutter
There was a problem hiding this comment.
yes, it will be closer to what we want
There was a problem hiding this comment.
updated, thank you for the great suggestion!
There was a problem hiding this comment.
Let's remove this and .gitignore it
| : 'the UI generation tool "${toolNames.first}"'; | ||
|
|
||
| return ''' | ||
| To show generated UI to user, use $toolDescription. |
There was a problem hiding this comment.
Keep in mind that this is being used with a confidential product, so this content is fine, but we won't be able to put product-specific stuff in here e.g. references to the specific catalog items etc.
There was a problem hiding this comment.
Sure!
The goal here is to construct a prompt that can be used in any app.
Contributes to #31