Rebuild Action Fails to Update Component UI, Contradicting Official Feature Announcement

[proptechbex]

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

The Rebuild Component and Rebuild Containing Page actions are not functioning as described in the official FlutterFlow documentation. When a component's input parameters are updated via page state, these actions fail to trigger a UI refresh within the component to reflect the new parameter values. This breaks the fundamental principle of creating reactive, state-driven components.

The component's UI remains static and does not update to reflect the new parameter values, even after explicitly triggering the rebuild actions. The actions appear to have no effect on the component's visual state.

Official Documentation Reference

The documentation states that these actions are used when "data changes dynamically" and you "want the latest data or UI state to be reflected instantly." My reproducible example shows that this is not happening.

Expected Behavior

According to the official feature announcement email, the Rebuild action should "refresh the current page, component, or its parent page... allowing your app UI to reflect those changes instantly." Therefore, when a parameter changes, the component's UI is expected to immediately re-render and display the new data.

Steps to Reproduce

1. Create a page with a DropDown widget that updates a page state variable (selectedValue).
2. Pass this selectedValue as a parameter (inputText) to a custom component.
3. The custom component contains a TextField that should display the inputText parameter. It also contains two buttons: one for the "Rebuild Component" action and one for the "Rebuild Containing Page" action.
4. Run the app and select a new value from the DropDown.
5. Observe that the TextField inside the component does not update.
6. Click the explicit rebuild buttons. Observe that they have no effect on the UI.

Reproducible from Blank

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

Bug Report Code (Required)

IT4ChvHlw85NofVb15DubsExhmAsH1whRY0w19Zxa0g3DZPND+x/esnRQFJuZ9OrdghhMWKWpHsKpqCMm9z1FfknHwyAf4hCzKpcEzvNQn+6RcWgO6iSWUB+GshbJmqE1qejgBBDIrB1c3AD3U2mDN6REyvUO4TIDUQZGfyKBNvXrgfuQ0SLb3kNh1JWeC/v

Visual documentation

The following images illustrate the issue. The page state updates correctly, but the component's UI fails to reflect this new state, even after explicitly triggering rebuild actions. You can also drag and drop these files directly into the GitHub issue form.

• Initial State: The DropDown shows "Option 1". The expected value text updates correctly, but the TextField inside the component does not.

• State Change with No Effect: After selecting "Option 2", the TextField remains unchanged. Critically, clicking the "Rebuild component" and "Rebuild page" buttons has no effect.

• Consistent Failure: The bug persists with "Option 3", confirming the failure of the rebuild actions to update the component's UI from its parameters.

Loom Video:

https://www.loom.com/share/a49dd885019444dd97f176320541a001?sid=45ee6b07-def6-469d-8843-fbbb73ea42dd

https://www.loom.com/share/3cfba306703f4c828bf0da97228c51b1?sid=929885e3-3644-498a-846e-993a8b9da6c4

Environment

- FlutterFlow version: Flutterflow v6.3.12+ realeased September 17, 2025
- Platform: Web
- Browser name and version: Chrome Versión 140.0.7339.128 (Build oficial) (64 bits)
- Operating system and version affected: Windows 11 Pro 24H2

Additional Information

This is a follow-up to the previously closed issue #6522, which was incorrectly classified as a support request. The core problem is a critical bug in the platform's rebuild logic that contradicts your official feature announcements.

As proof, I have attached a screenshot of the product update email from August 6, 2025, which introduced the "Rebuild Action." The email clearly states its purpose is to "refresh the... component... allowing your app UI to reflect those changes instantly." My reproducible example proves this functionality is broken.

The workaround of using setFormField is not a solution. It's unmanageable in a real-world application with over 70 complex components that rely on reactive updates based on their parameters. This bug fundamentally breaks component-based architecture in FlutterFlow.

Please investigate this as a high-priority bug based on this clear evidence.

[Alezanello]

Hello!

This isn’t a bug—it’s the expected behavior. A TextField value is only set when the widget initializes. Any new updates must go through the Set Form Field action.

I understand it can feel frustrating, but this is actually a Flutter limitation (not something specific to FlutterFlow). As you can see in this StackOverflow discussion: How do you change the value inside of a TextField (Flutter)?, the only way for a TextField to reflect a new value is by explicitly replacing its value.

In FlutterFlow, this is done using the Set Form Field action. So while it may not seem like a direct solution, it is currently the expected and correct approach.

[proptechbex]

Hello @Alezanello ,

Thank you for the detailed response and the link to the Stack Overflow discussion.

I understand the technical nuances of TextEditingController in native Flutter. However, my bug report has been fundamentally misinterpreted. The TextField widget was only used as a simple, visual example to demonstrate a much deeper, critical issue: the Rebuild Component action does not function as documented.

Let's completely forget about the TextField for a moment and discuss the core architectural problem.

The Purpose of a "Rebuild Component" Action

The entire purpose of a tool like FlutterFlow is to abstract away Flutter's complexities. Your official documentation promises that the Rebuild Component action will "refresh only that specific component" to reflect the "latest data or UI state instantly."

When a component's input parameters change, a "rebuild" should logically trigger a re-initialization of that component's state, causing it to render with the new parameter values. If the action cannot do this, then it fails to fulfill its documented purpose. Blaming a "Flutter limitation" is not a valid argument when the action itself is a FlutterFlow abstraction designed to handle these exact scenarios.

The "Set Form Field" Workaround is Not a Solution

Your proposed solution of using Set Form Field from the parent page is architecturally flawed and completely unscalable. As I mentioned previously, I am building a real-world application with over 70 complex, reusable components. These components are designed to be self-contained "black boxes" that manage their own internal logic based on their input parameters.

Forcing the parent page to have intimate knowledge of the internal widgets of every single component (TextField1, Chart2, DataColumn5, etc.) defeats the entire purpose of component-based development. It creates tightly coupled, brittle code that is impossible to maintain.

This is a critical architectural flaw, not a widget-specific quirk. I strongly urge you to escalate this for a genuine review of the Rebuild action's core functionality, as it is fundamental to building any scalable application on your platform.

Best regards.

[Alezanello]

Hello again!

Thank you for sharing the details. I believe there might be a slight misunderstanding of what this feature actually does. As shown in the documentation image you provided, this action performs a refresh, not a re-initialization of the component, page, or app.

A refresh simply updates the UI with the latest state changes. It does not re-initialize the component, page, or app, which is why certain widgets that rely on re-initialization won’t have their values updated.

[github-actions]

This issue is stale because it has been open for 7 days with no activity. If there are no further updates, a team member will close the issue.

[Alezanello]

Closing this issue since we haven't heard back from you. If you are still facing the problem please submit a new issue. Thank you!