MCP: Unable to Calendar widget's selected date — WidgetState coverage incomplete

[sgardoll]

Summary

The FlutterFlow AI MCP cannot author Calendar.onSelectedDateChanged.

The DSL's WidgetState(widgetName, property) expression — the documented way to read a widget's runtime value — explicitly excludes Calendar and exposes only value, text, and currentIndex (WidgetStateProperty enum). value is hard-coded to a closed list of widget types (Toggle, Checkbox, Dropdown, Slider, RadioGroup, PinCode) and throws if used against a Calendar.

The underlying proto clearly supports this — the editor produces actions that read Calendar's selected date — but the DSL surface doesn't expose the variable source/operation tree needed to construct one, and there is no documented example to reverse-engineer from.

Repro

In a FlutterFlow project, attempt the following via the flutterflow_ai DSL:

app.editPage('Daily', (page) {
  page.ensureActions(
    page.findByName('Calendar'),
    triggerType: FFActionTriggerType.ON_DATE_SELECTED,
    actions: [
      SetState('selectedDay', WidgetState('Calendar', WidgetStateProperty.value)),
    ],
  );
});

Result: Throws at compile time:

StateError: WidgetState(Calendar, value) requires a Toggle, Checkbox, Dropdown, Slider, RadioGroup, or PinCode target.

Source: .flutterflow/sdk/flutterflow_ai/lib/src/dsl/compiler.dart:7651-7663 (_widgetValueTypeForDslWidget).

Why this matters

This is a normal binding that any builder can do in two clicks in the FF editor:

Calendar → Actions → On Selected Date Changed → Update Page State → field = Calendar Widget State → Selected Date → Start Date

Every Calendar-on-a-page workflow needs it: filtering a list by day, navigating between days, querying date-scoped data. There's no DSL workaround short of writing raw protobuf, which:

1. Has no documented example to crib from anywhere in references/, docs api-surface, or docs ui.
2. Requires guessing the FFVariableSource / FFBaseVariable.widgetState shape for a non-action widget value (the existing FFWidgetStateVariable_ActionVariableType enum covers UPLOAD_DATA_URL, DATE_PICKER, TIMER_*, etc. — nothing for Calendar).
3. Will silently break with any future schema rev because it's bypassing the typed surface.

Environment

• flutterflow_ai SDK version: latest as of 2026-05-18
• DSL files: dsl/edit.dart

[Alezanello]

⏺ Hi! There's no clean DSL surface for Calendar.selectedDate* yet, but here's a working app.raw(...) escape hatch based on inspecting the SDK source.

The idea: the FlutterFlow editor produces this binding as FFVariableSource.WIDGET_STATE + an FFVariableOperation.dateTimeRangeStart operation chained on the variable.

We construct that proto shape directly via app.raw(...).

import 'package:flutterflow_ai/flutterflow_ai.dart';
import 'package:flutterflow_ai/src/ui/actions.dart' show Actions;
import 'package:flutterflow_ai/src/helpers/state_update.dart' show StateFieldUpdate;

void _build(App app) {app.appStateField('selectedDay', dateTime);
app.editPage('Daily', (page) {
  app.raw((project) {
    final pageClass = project.getWidgetClassByName('Daily')!;
    final calendarNode = _findByName(pageClass.node, 'Calendar', FFWidgetType.Calendar)!;
    // The FFVariable the DSL doesn't expose today.
    final selectedStart = FFVariable(
      source: FFVariableSource.WIDGET_STATE,
      nodeKeyRef: FFNodeKeyReference(key: calendarNode.key),
      baseVariable: FFBaseVariable(
        widgetState: FFWidgetStateVariable(
          returnParameter: FFParameter(
            dataType: FFDataTypeV2(scalarType: FFBaseDataType.TimestampRange),
          ),
        ),
      ),
      operations: [
        FFVariableOperation(dateTimeRangeStart: FFDateTimeRangeStart()),
        // swap to dateTimeRangeEnd: FFDateTimeRangeEnd() for the end date
      ],
    );
    final action = Actions.updateAppState(
      project,
      updates: [StateFieldUpdate.setFromVariable('selectedDay', selectedStart)],
    );
    // Make the script rerun-safe.
    calendarNode.triggerActions.removeWhere(
      (t) => t.trigger.triggerType == FFActionTriggerType.ON_DATE_SELECTED,
    );
    Actions.addTriggerChain(
      calendarNode,
      FFActionTriggerType.ON_DATE_SELECTED,
      FFActionNode(key: generateActionKey(), action: action),
    );
  });
});
}

FFNode? _findByName(FFNode root, String name, FFWidgetType type) {

if (root.type == type && root.name == name) return root;
for (final c in root.children) {
  final hit = _findByName(c, name, type);
  if (hit != null) return hit;
}
return null;

}

Notes:

• For page state instead of app state: use Actions.updatePageState(project, widgetClassName: 'Daily', updates: [...]).
• The Actions and StateFieldUpdate imports come from src/ — they're not in the public re-export, but the path imports work fine.
• After your first push, open the project in the FF editor and check the Calendar's action panel — it should display exactly as if you had wired it through the UI

(Update App State → selectedDay → Calendar Widget State → Selected Date → Start Date).

• This is fragile to schema bumps. Once the team ships a proper WidgetStateProperty.selectedDateStart surface, migrate off this.