Skip to content

Comments

Use DropdownMenuEntry<Object> for type safety#452

Open
jogendra-flutter wants to merge 1 commit intoStacDev:devfrom
jogendra-flutter:dev
Open

Use DropdownMenuEntry<Object> for type safety#452
jogendra-flutter wants to merge 1 commit intoStacDev:devfrom
jogendra-flutter:dev

Conversation

@jogendra-flutter
Copy link

@jogendra-flutter jogendra-flutter commented Feb 20, 2026


Title: fix: use DropdownMenuEntry<Object> to fix type assignment error


This replaces implicit dynamic usage with DropdownMenuEntry<Object> to satisfy the analyzer and improve type safety.

Description

DropdownMenu.dropdownMenuEntries expects List<DropdownMenuEntry<Object>>, but the previous code produced List<DropdownMenuEntry<dynamic>> in two places:

  • .whereType<DropdownMenuEntry>() — missing the <Object> type parameter, defaulting to dynamic
  • const <DropdownMenuEntry<dynamic>>[] — fallback list explicitly typed as dynamic

Because Dart's generics are invariant, List<DropdownMenuEntry<dynamic>> is not assignable to List<DropdownMenuEntry<Object>>, causing a compile-time error on newer Flutter/Dart SDK versions.

Fix: Added <Object> to both expressions so the unified type resolves to List<DropdownMenuEntry<Object>>.

// Before
.whereType<DropdownMenuEntry>().toList() ?? const <DropdownMenuEntry<dynamic>>[]

// After
.whereType<DropdownMenuEntry<Object>>().toList() ?? const <DropdownMenuEntry<Object>>[]

Related Issues

Closes #

Type of Change

  • New feature (non-breaking change which adds functionality)
  • Bug fix (non-breaking change which fixes an issue)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • Code refactor
  • Build configuration change
  • Documentation
  • Chore

Summary by CodeRabbit

  • Refactor
    • Improved type safety in the dropdown menu component through more specific type constraints.

This replaces implicit dynamic usage with DropdownMenuEntry<Object> to satisfy the analyzer and improve type safety.
@CLAassistant
Copy link

CLAassistant commented Feb 20, 2026

CLA assistant check
All committers have signed the CLA.

@coderabbitai
Copy link
Contributor

coderabbitai bot commented Feb 20, 2026

📝 Walkthrough

Walkthrough

A type safety improvement narrowing dropdown menu entry filters from DropdownMenuEntry<dynamic> to DropdownMenuEntry<Object> in the dropdown menu parser widget builder, with no alterations to control flow or functional logic.

Changes

Cohort / File(s) Summary
Type Narrowing in Dropdown Menu
packages/stac/lib/src/parsers/widgets/stac_dropdown_menu/stac_dropdown_menu_parser.dart
Narrowed type filters for dropdown entries from dynamic to Object in both whereType() usage and default list initialization within the _DropDownMenuWidgetState.build method.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~5 minutes

Poem

🐰 A dropdown now speaks with a voice more clear,
From dynamic's fog to Object's frontier,
Type safety wins, no logic astray,
Safer code hops into the day! 🌟

🚥 Pre-merge checks | ✅ 3
✅ Passed checks (3 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title 'Use DropdownMenuEntry for type safety' accurately reflects the main change: replacing dynamic with Object type parameter for better type safety in dropdown menu entries.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment

Tip

Issue Planner is now in beta. Read the docs and try it out! Share your feedback on Discord.


Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 Nitpick comments (2)
packages/stac/lib/src/parsers/widgets/stac_dropdown_menu/stac_dropdown_menu_parser.dart (2)

41-42: Pre-existing resource leak: TextEditingController and FocusNode are never disposed.

Neither _controller nor _focusNode overrides dispose(), which will leak resources when the widget is removed from the tree. This is not introduced by this PR, but the widget is touched here so it's worth addressing.

♻️ Proposed fix — add a dispose override
+  `@override`
+  void dispose() {
+    _controller.dispose();
+    _focusNode.dispose();
+    super.dispose();
+  }
+
   `@override`
   Widget build(BuildContext context) {
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In
`@packages/stac/lib/src/parsers/widgets/stac_dropdown_menu/stac_dropdown_menu_parser.dart`
around lines 41 - 42, The widget creates a TextEditingController (_controller)
and a FocusNode (_focusNode) but never disposes them; add an override of
dispose() in the widget's State class (the state that owns
_controller/_focusNode in stac_dropdown_menu_parser) that calls
_controller.dispose(); _focusNode.dispose(); and then super.dispose() to prevent
the resource leak.

41-42: Pre-existing resource leak: TextEditingController and FocusNode are never disposed.

Neither _controller nor _focusNode has a corresponding dispose() call. This isn't introduced by this PR but is worth tracking to avoid memory/resource leaks.

♻️ Proposed fix — add a `dispose` override
+  `@override`
+  void dispose() {
+    _controller.dispose();
+    _focusNode.dispose();
+    super.dispose();
+  }
+
   `@override`
   Widget build(BuildContext context) {
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In
`@packages/stac/lib/src/parsers/widgets/stac_dropdown_menu/stac_dropdown_menu_parser.dart`
around lines 41 - 42, The TextEditingController (_controller) and FocusNode
(_focusNode) are never disposed; add an override of dispose() in the State class
that owns these fields (the State subclass in stac_dropdown_menu_parser.dart)
and call dispose on both _controller and _focusNode before calling
super.dispose(); ensure you reference TextEditingController and FocusNode and
place the dispose logic in the same class where those fields are declared.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In
`@packages/stac/lib/src/parsers/widgets/stac_dropdown_menu/stac_dropdown_menu_parser.dart`:
- Around line 41-42: The widget creates a TextEditingController (_controller)
and a FocusNode (_focusNode) but never disposes them; add an override of
dispose() in the widget's State class (the state that owns
_controller/_focusNode in stac_dropdown_menu_parser) that calls
_controller.dispose(); _focusNode.dispose(); and then super.dispose() to prevent
the resource leak.
- Around line 41-42: The TextEditingController (_controller) and FocusNode
(_focusNode) are never disposed; add an override of dispose() in the State class
that owns these fields (the State subclass in stac_dropdown_menu_parser.dart)
and call dispose on both _controller and _focusNode before calling
super.dispose(); ensure you reference TextEditingController and FocusNode and
place the dispose logic in the same class where those fields are declared.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants