debugFillProperties method

  1. @override
void debugFillProperties (DiagnosticPropertiesBuilder properties)
inherited

Add additional properties associated with the node.

Use the most specific DiagnosticsProperty existing subclass to describe each property instead of the DiagnosticsProperty base class. There are only a small number of DiagnosticsProperty subclasses each covering a common use case. Consider what values a property is relevant for users debugging as users debugging large trees are overloaded with information. Common named parameters in DiagnosticsNode subclasses help filter when and how properties are displayed.

defaultValue, showName, showSeparator, and level keep string representations of diagnostics terse and hide properties when they are not very useful.

  • Use defaultValue any time the default value of a property is uninteresting. For example, specify a default value of null any time a property being null does not indicate an error.
  • Avoid specifying the level parameter unless the result you want cannot be achieved by using the defaultValue parameter or using the ObjectFlagProperty class to conditionally display the property as a flag.
  • Specify showName and showSeparator in rare cases where the string output would look clumsy if they were not set.
    DiagnosticsProperty<Object>('child(3, 4)', null, ifNull: 'is null', showSeparator: false).toString()
    
    Shows using showSeparator to get output child(3, 4) is null which is more polished than child(3, 4): is null.
    DiagnosticsProperty<IconData>('icon', icon, ifNull: '<empty>', showName: false)).toString()
    
    Shows using showName to omit the property name as in this context the property name does not add useful information.

ifNull, ifEmpty, unit, and tooltip make property descriptions clearer. The examples in the code sample below illustrate good uses of all of these parameters.

DiagnosticsProperty subclasses for primitive types

  • StringProperty, which supports automatically enclosing a String value in quotes.
  • DoubleProperty, which supports specifying a unit of measurement for a double value.
  • PercentProperty, which clamps a double to between 0 and 1 and formats it as a percentage.
  • IntProperty, which supports specifying a unit of measurement for an int value.
  • FlagProperty, which formats a bool value as one or more flags. Depending on the use case it is better to format a bool as DiagnosticsProperty<bool> instead of using FlagProperty as the output is more verbose but unambiguous.

Other important DiagnosticsProperty variants

  • EnumProperty, which provides terse descriptions of enum values working around limitations of the toString implementation for Dart enum types.
  • IterableProperty, which handles iterable values with display customizable depending on the DiagnosticsTreeStyle used.
  • ObjectFlagProperty, which provides terse descriptions of whether a property value is present or not. For example, whether an onClick callback is specified or an animation is in progress.

If none of these subclasses apply, use the DiagnosticsProperty constructor or in rare cases create your own DiagnosticsProperty subclass as in the case for TransformProperty which handles Matrix4 that represent transforms. Generally any property value with a good toString method implementation works fine using DiagnosticsProperty directly.

Used by toDiagnosticsNode and toString.

Implementation

@override
void debugFillProperties(DiagnosticPropertiesBuilder properties) {
  super.debugFillProperties(properties);
  assert(() {
    properties.add(EnumProperty<_StateLifecycle>('lifecycle state', _debugLifecycleState, defaultValue: _StateLifecycle.ready));
    return true;
  }());
  properties.add(ObjectFlagProperty<T>('_widget', _widget, ifNull: 'no widget'));
  properties.add(ObjectFlagProperty<StatefulElement>('_element', _element, ifNull: 'not mounted'));
}