Skip to content

Persistent Issues with Custom Widget Parameter Inference, Settings, and Callbacks #5733

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

Open
1 of 2 tasks
JKern100 opened this issue Apr 23, 2025 · 7 comments
Open
1 of 2 tasks
Assignees
Labels
status: not a bug This is not a bug.

Comments

@JKern100
Copy link

JKern100 commented Apr 23, 2025

Can we access your project?

  • I give permission for members of the FlutterFlow team to access and test my project for the sole purpose of investigating this issue.

Current Behavior

I am experiencing significant and persistent issues when trying to create and configure a Custom Widget that uses an external package (flutter_chess_board) and needs to expose a callback parameter to trigger actions in the FlutterFlow page.

The problems appear to be related to how FlutterFlow infers parameters from the Custom Widget code, synchronizes settings, and handles callback definitions in the Widget Settings panel.

Observed Behavior:

Inconsistent and Stale Compilation Errors: The environment frequently displayed compilation errors that did not correspond to the code currently in the editor. This included seeing old errors from previous code versions after pasting new, correct code, and even seeing nonsensical compilation errors on the default boilerplate code of a newly created Custom Widget. Failure to Process Complex Parameter Types: Attempts to save the Custom Widget with parameters of complex types like function signatures (Future Function(...)?, VoidCallback?) or ValueNotifier? defined in the code resulted in "Unable to process parameter" errors. (Example: "Unable to process parameter 'newFenNotifier'"). Incorrect Parameter Inference and Display in Widget Settings: When a function parameter was defined in the code (e.g., final Future Function(String newFen)? onMove;), it was consistently not inferred as an "Action" type or displayed in the "Callbacks" section. Instead, it appeared under the "Define Parameters" section with an inferred function type (Future Function(String newFen)). Even for standard parameters (width, height - Double?), the "Define Parameters" section did not reliably reflect the parameters defined in the code. Manually adding these parameters in the settings would sometimes result in them disappearing from the settings panel upon saving, even though the code did define them, suggesting a sync issue where the settings were reverting to an incorrect state based on a faulty inference. Missing "Callbacks" Section: The dedicated "Callbacks" section in the Custom Widget Settings panel, where users are supposed to configure Action parameters inferred from the code, was consistently missing throughout the troubleshooting process, despite attempts to define a function parameter in the code intended as a callback and confirming that "Action" is a selectable type for new parameters in the settings. Impact:

These issues make it extremely difficult or impossible to properly configure Custom Widget parameters and expose callback events to the FlutterFlow action system, which is necessary for interactive widgets that need to send data back to the page logic.

Expected Behavior

Expected Behavior (Based on Documentation and Standard Functionality):

When defining parameters (like double? width, String initialFen, Future Function(String)? onMove) in the Custom Widget code (constructor and properties), FlutterFlow should automatically infer these parameters and display them correctly in the "Define Parameters" section of the Widget Settings panel. Function parameters intended as callbacks (like Future Function(String)? onMove) should be recognized by FlutterFlow as "Action" type parameters and be listed and configurable within a dedicated "Callbacks" section in the Widget Settings panel. Compilation errors displayed in the editor should accurately reflect the code currently in the editor. Saving the widget should consistently synchronize the Widget Settings panel with the parameters defined in the code, especially when confirming parameter mismatches.

Steps to Reproduce

Steps Taken During Troubleshooting (May help with reproduction):

Attempting to save Custom Widget code with various parameter types (String, Double, Function, ValueNotifier). Clicking "Yes" on the "Parameters in the settings don't match..." dialog multiple times. Manually adding parameters (like width, height) in the "Define Parameters" section and observing their disappearance after saving. Using the "Compile Code" button to force recompilation and clear stale errors. Deleting and recreating the Custom Widget from scratch. Performing hard refreshes of the FlutterFlow environment.

Reproducible from Blank

  • The steps to reproduce above start from a blank project.

Bug Report Code (Required)

??

Visual documentation

Image

Environment

- FlutterFlow version: FlutterFlow v5.4.4 released April 22, 2025
Flutter version is 3.27.3
- Platform: web
- Browser name and version: Chrome Version 135.0.7049.96 (Official Build) (64-bit)
- Operating system and version affected: MS

Additional Information

No response

@JKern100 JKern100 added the status: needs triage A potential issue that has not been confirmed as a bug. label Apr 23, 2025
Copy link
Collaborator

Hello!

To help us investigate this issue more thoroughly, could you please share the bug report code for your project?

You can find it by going to the Widget Tree, right-clicking on any widget, and selecting "Get Bug Report Code" from the pop-up menu.

Thanks in advance!

@Alezanello Alezanello self-assigned this Apr 23, 2025
@Alezanello Alezanello removed the status: needs triage A potential issue that has not been confirmed as a bug. label Apr 23, 2025
@Alezanello Alezanello added the status: needs information More information/context is needed for assessment. label Apr 23, 2025 — with Linear
@JKern100
Copy link
Author

JKern100 commented Apr 23, 2025 via email

@JKern100
Copy link
Author

Any news? We're stuck on this.

Copy link
Collaborator

Hello again!

I just copied and pasted your custom widget into a new blank project without making any changes, and it compiled successfully without any errors.
Please try clicking the Compile button at the top again to see if the issue still occurs on your end.

If the problem persists, I recommend reaching out to our support team via the in-app chat or by emailing support@flutterflow.io — they have the right tools to assist you more deeply.

You can also review the public project I created here: QA-4023 Public Project.

Hope this helps!

@Alezanello Alezanello removed the status: needs information More information/context is needed for assessment. label Apr 25, 2025
@Alezanello Alezanello added the status: can't reproduce Following the reported steps did not reproduce the bug. label Apr 25, 2025 — with Linear
@JKern100
Copy link
Author

JKern100 commented Apr 26, 2025 via email

@thethinkingman
Copy link

thethinkingman commented Apr 28, 2025

In response (it may clarify your request):

When defining parameters (like double? width, String initialFen, Future Function(String)? onMove) in the Custom Widget code (constructor and properties), FlutterFlow should automatically infer these parameters and display them correctly in the "Define Parameters" section of the Widget Settings panel. Function parameters intended as callbacks (like Future Function(String)? onMove) should be recognized by FlutterFlow as "Action" type parameters and be listed and configurable within a dedicated "Callbacks" section in the Widget Settings panel.

In my experience, the editor does work like that. It does not work the other way around.
After adding parameters in the editor you cannot add them using the GUI.

If your expectation is that after defining the parameter in the editor FlutterFlow will update the GUI realtime, then I don't think that the developers would do that.

I am happy that it updates the parameters on Save - in this instance.

Compilation errors displayed in the editor should accurately reflect the code currently in the editor.

I guess that as you can compile whilst the current changes have not been saved it can cause confusion.

It would be nice if FlutterFlow could disable the Compile button when the code in the editor has changed, thus forcing a Save first.

I too have run into that situation.

I also think that the Save and Compile buttons should be separated from the Launch in Browser button, as I find myself clicking on it sometimes by mistake. Annoying.

Saving the widget should consistently synchronize the Widget Settings panel with the parameters defined in the code, especially when confirming parameter mismatches.

I agree.

Currently this message appears: "Parameters in the settings don't match parameters in the code editor. If you confirm, we will replace parameters in the settings with parameters in the code editor. Are you sure you want to proceed?"

I suspect that the developers have a dilemma using the current approach - as the user could press the Save button at any time. Because of this, if the user removed other parameters in the code, or changed things completely then the developers would need to handle that. They probably put it in the too hard basket.

To satisfy you and me it should really update the editor as soon as the parameter is added using the GUI.

An idea would be to have a Save button for each parameter - before it is added. You would then need to have an Edit button to - so that you can modify it if needed.

An alternative approach would be to add new parameters using a dialog box. This forces the user to then Save or Cancel the change.

I hope that my feedback helps.

Perhaps some feature requests are needed.

Copy link
Collaborator

Thank you for bringing this up — you are absolutely right, and I appreciate your attention to detail. After reviewing the situation, I can confirm that the issue you’re encountering is not caused by the FlutterFlow editor itself, but rather by the code being inserted into the Custom Widget.

If you download the project code and open it in VS Code, you’ll see the same errors highlighted there as well. I recommend reviewing and correcting the code locally to ensure it’s error-free. Once the issues are resolved, you can upload the updated code back into FlutterFlow or push it using the FlutterFlow VS Code extension.

Please also note that FlutterFlow does not provide direct support for custom code. Additionally, this GitHub Issue Tracker is specifically intended for reporting issues caused by the FlutterFlow platform itself, not by custom code implementations.

image.png

@Alezanello Alezanello removed the status: can't reproduce Following the reported steps did not reproduce the bug. label Apr 28, 2025
@Alezanello Alezanello added the status: not a bug This is not a bug. label Apr 28, 2025 — with Linear
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: not a bug This is not a bug.
Projects
None yet
Development

No branches or pull requests

3 participants