Add an option to set a Dismissble as 'active'

[diablodale]

Attempt to disable the Dismissible() behavior by setting .direction = null causes assert at https://github.com/flutter/flutter/blob/6d134e0c866ce90a4dc7a02af6a8f1079c2a4fdc/packages/flutter/lib/src/widgets/dismissible.dart#L337

This is a feature enhancement to simplify customer code, not a code fault.

Setup

Flutter version 0.11.9 Framework revision d48e6e433c (5 days ago), 2018-11-20 22:05:23 -0500 Engine revision 5c8147450d Dart version 2.1.0 (build 2.1.0-dev.9.4 f9ebf21297) Platform android-27, build-tools 27.0.3

Repo Scenario

• ListView containing many Dismissible()
• Dismissible's contain a card
• Sometimes, all these cards can not be dismissed. There should be no sliding possible
• Sometimes, all these cards can be dismissed. Slide to remove them.

It would be desired to use the Dismissible.direction field to set the means to be dismissed. With flutter v0.11.9, we can set that field to any choice of DismissDirection but unfortunately not to null. Naturally, null as a .direction would indicate there is no direction in which it can be dismissed...making the Dismissible a noop.

Support for null as a value to Dismissible.direction will simply customer code. Rather than using a condition expression and duplicating the child widget code, it can more easily be done by just setting the direction to null.

Today's unhappy duplicate code 😐

Listview.builder(...
  itemBuilder:
    return isDisabled ?
      CardWidgetAndCode(
        ...
      )
    : Dismissible(
      child: CardWidgetAndCode( //  <-- duplicate code and/or function call
        ...
      )
    )
)

Future happy simplified code 🙂

Listview.builder(...
  itemBuilder:
    Dismissible(
      direction: isDisabled ? null : DismissDirection.horizontal,
      child: CardWidgetAndCode(
        ...
      )
    )
)

Log of assert

package:flutter/src/widgets/dismissible.dart': Failed assertion: line 337 pos 12: 'widget.direction != null': is not true

Doctor

[√] Flutter (Channel beta, v0.11.9, on Microsoft Windows [Version 10.0.17763.165], locale en-US)
    • Flutter version 0.11.9 at C:\Users\dale\.flutter
    • Framework revision d48e6e433c (5 days ago), 2018-11-20 22:05:23 -0500
    • Engine revision 5c8147450d
    • Dart version 2.1.0 (build 2.1.0-dev.9.4 f9ebf21297)

[√] Android toolchain - develop for Android devices (Android SDK 27.0.3)
    • Android SDK at C:\Users\dale\.android\Sdk
    • Android NDK location not configured (optional; useful for native profiling support)
    • Platform android-27, build-tools 27.0.3
    • ANDROID_HOME = C:\Users\dale\.android\Sdk
    • Java binary at: C:\Program Files\Android\android-studio-preview\jre\bin\java
    • Java version OpenJDK Runtime Environment (build 1.8.0_152-release-1136-b06)
    • All Android licenses accepted.

[√] Android Studio (version 3.2)
    • Android Studio at C:\Program Files\Android\android-studio-preview
    • Flutter plugin version 30.0.1
    • Dart plugin version 181.5656
    • Java version OpenJDK Runtime Environment (build 1.8.0_152-release-1136-b06)

[√] VS Code, 64-bit edition (version 1.29.1)
    • VS Code at C:\Program Files\Microsoft VS Code
    • Flutter extension version 2.20.0

[√] Connected device (1 available)
    • Android SDK built for x86 • emulator-5554 • android-x86 • Android 8.0.0 (API 26) (emulator)

• No issues found!

[Sub6Resources]

Created a pull request for this issue: #36613

[Piinks]

@goderbauer and I chatted offline about making this change and we have closed the associated PR. Using a Dismissible widget should be dismissible, and making the direction nullable creates a weird api without a clear intention. If you would like to simplify code to 'enable/disable' the Dismissible, you can easily create a wrapper widget that handles that for you. :) I'm going to close this issue then, feel free to discuss further if you think the assert is incorrect.

[diablodale]

I disagree with your assessment. However without the above conversation being public, there is no way that I can participate in it.

[Sub6Resources]

I also disagree and would also have appreciated it if the discussion happened on GitHub.

[Piinks]

Glad to hear! The discussion actually took place on the PR: #48921 The extent of our offline chat was to just close the issue given the comments on the PR. There are a number of concerns around removing the assert on the direction, as it introduces the opportunity for exceptions to fire elsewhere that rely on that assertion. Feel free to discuss further! :)

[Piinks]

Based on the PR feedback, I'm going to re-open this and re-name it for the newly proposed api change. Feel free to continue discussing here and thanks for the input! :)

[bounty1342]

Hi,

Why not just add a DismissDirection.none ?

Regards,

[HelgeSverre]

Regarding the code duplication issue mentioned earlier, here's a simple technique that can be used as an alternative:

class ExampleWidget extends StatelessWidget {
  final DismissDirectionCallback? onDismissed;
  final String text;

  const ExampleWidget({
    required this.text,
    this.onDismissed,
    super.key,
  });

  @override
  Widget build(BuildContext context) {
    // Define the core widget
    var item = Container(
      padding: const EdgeInsets.all(10),
      color: Colors.blue,
      child: Text(text, style: const TextStyle(color: Colors.black)),
    );

    // Conditionally wrap in Dismissible
    if (onDismissed != null) {
      return Dismissible(
        key: ObjectKey(text),
        onDismissed: onDismissed,
        child: item,
      );
    }

    return item;
  }
}

This approach demonstrates how to avoid duplicating widget code when conditionally applying a Dismissible wrapper. By assigning the core widget to a variable first, we can easily return either the wrapped or unwrapped version without repeating the widget's definition.

While this doesn't solve the original issue, I think it is a somewhat neat and clean way to achieve effectively the same thing.

If anyone knows of any reasons why this approach should not be used (e.g., performance issues, potential bugs this might cause), please feel free to correct me.

[diablodale]

@HelgeSverre thanks for the interesting example. I don't have a current Flutter project to experiment with it. The issue seems to be one that appears more than once, and your example may be workaround for the ongoing core gap in feature/functionality.