build method
- BuildContext context
Describes the part of the user interface represented by this widget.
The framework calls this method in a number of different situations. For example:
- After calling initState.
- After calling didUpdateWidget.
- After receiving a call to setState.
- After a dependency of this State object changes (e.g., an InheritedWidget referenced by the previous build changes).
- After calling deactivate and then reinserting the State object into the tree at another location.
This method can potentially be called in every frame and should not have any side effects beyond building a widget.
The framework replaces the subtree below this widget with the widget returned by this method, either by updating the existing subtree or by removing the subtree and inflating a new subtree, depending on whether the widget returned by this method can update the root of the existing subtree, as determined by calling Widget.canUpdate.
Typically implementations return a newly created constellation of widgets that are configured with information from this widget's constructor, the given BuildContext, and the internal state of this State object.
The given BuildContext contains information about the location in the
tree at which this widget is being built. For example, the context
provides the set of inherited widgets for this location in the tree. The
BuildContext argument is always the same as the context property of
this State object and will remain the same for the lifetime of this
object. The BuildContext argument is provided redundantly here so that
this method matches the signature for a WidgetBuilder.
Design discussion
Why is the build method on State, and not StatefulWidget?
Putting a Widget build(BuildContext context) method on State rather
than putting a Widget build(BuildContext context, State state) method
on StatefulWidget gives developers more flexibility when subclassing
StatefulWidget.
For example, AnimatedWidget is a subclass of StatefulWidget that
introduces an abstract Widget build(BuildContext context) method for its
subclasses to implement. If StatefulWidget already had a build method
that took a State argument, AnimatedWidget would be forced to provide
its State object to subclasses even though its State object is an
internal implementation detail of AnimatedWidget.
Conceptually, StatelessWidget could also be implemented as a subclass of StatefulWidget in a similar manner. If the build method were on StatefulWidget rather than State, that would not be possible anymore.
Putting the build function on State rather than StatefulWidget also
helps avoid a category of bugs related to closures implicitly capturing
this. If you defined a closure in a build function on a
StatefulWidget, that closure would implicitly capture this, which is
the current widget instance, and would have the (immutable) fields of that
instance in scope:
// (this is not valid Flutter code)
class MyButton extends StatefulWidgetX {
MyButton({super.key, required this.color});
final Color color;
@override
Widget build(BuildContext context, State state) {
return SpecialWidget(
handler: () { print('color: $color'); },
);
}
}
For example, suppose the parent builds MyButton with color being blue,
the $color in the print function refers to blue, as expected. Now,
suppose the parent rebuilds MyButton with green. The closure created by
the first build still implicitly refers to the original widget and the
$color still prints blue even through the widget has been updated to
green; should that closure outlive its widget, it would print outdated
information.
In contrast, with the build function on the State object, closures created during build implicitly capture the State instance instead of the widget instance:
class MyButton extends StatefulWidget {
const MyButton({super.key, this.color = Colors.teal});
final Color color;
// ...
}
class MyButtonState extends State<MyButton> {
// ...
@override
Widget build(BuildContext context) {
return SpecialWidget(
handler: () { print('color: ${widget.color}'); },
);
}
}
Now when the parent rebuilds MyButton with green, the closure created by
the first build still refers to State object, which is preserved across
rebuilds, but the framework has updated that State object's widget
property to refer to the new MyButton instance and ${widget.color}
prints green, as expected.
See also:
- StatefulWidget, which contains the discussion on performance considerations.
Implementation
@override
Widget build(BuildContext context) {
String sortByAssociation =
ref.read(sortByAssociationProvider.notifier).state;
bool basketsTicked = ref.read(basketsAssociationProvider.notifier).state;
return Column(
spacing: configRowSpace,
children: [
configTopGap,
Row(
spacing: configWidgetSpace,
children: [
// Space to the left of the configs.
const SizedBox(width: 5),
// The BUILD button.
ActivityButton(
onPressed: () async {
if (context.mounted)
await rSource(
context,
ref,
['model_template', 'model_build_association'],
);
await ref.read(associationControllerProvider).animateToPage(
// Index of the second page.
1,
duration: const Duration(milliseconds: 300),
curve: Curves.easeInOut,
);
},
child: const Text('Build Association Rules'),
),
Text('Target: ${getTarget(ref)}'),
LabelledCheckbox(
key: const Key('basketsAssociationField'),
tooltip: '''
If checked, baskets are identified by the ident variable and items
in the basket by the target variable. Otherwise a basket is the
collection of input variables.
''',
label: 'Baskets',
provider: basketsAssociationProvider,
onSelected: (ticked) {
setState(() {
if (ticked != null) {
ref.read(basketsAssociationProvider.notifier).state =
ticked;
}
});
},
),
],
),
Row(
spacing: configWidgetSpace,
children: [
configLeftGap,
NumberField(
label: 'Support:',
key: const Key('supportAssociationField'),
controller: _supportController,
tooltip: '''
Support measures how frequently an item or itemset appears
in a dataset, indicating its ove.
''',
inputFormatter: FilteringTextInputFormatter.allow(
RegExp(r'^[0-9]*\.?[0-9]{0,4}$'),
),
validator: (value) => validateDecimal(value),
stateProvider: supportAssociationProvider,
interval: 0.005,
decimalPlaces: 4,
),
NumberField(
label: 'Confidence:',
key: const Key('confidenceAssociationField'),
controller: _confidenceController,
tooltip: '''
Confidence measures the likelihood that an item appears in transactions
containing another item, indicating the strength of the rule.
''',
inputFormatter: FilteringTextInputFormatter.allow(
RegExp(r'^[0-9]*\.?[0-9]{0,4}$'),
),
validator: (value) => validateDecimal(value),
stateProvider: confidenceAssociationProvider,
interval: 0.005,
decimalPlaces: 4,
),
NumberField(
label: 'Min Length:',
key: const Key('minLengthAssociationField'),
controller: _minLengthController,
tooltip: '''
Min length sets the minimum number of items in the itemsets or
rules generated, controlling the complexity of the rules.
''',
inputFormatter:
FilteringTextInputFormatter.digitsOnly, // Integers only
validator: validateVector,
stateProvider: minLengthAssociationProvider,
),
NumberField(
label: 'Limit Rules:',
key: const Key('measuresLimitAssociationField'),
controller: _limitNumberMeasureController,
tooltip: '''
Limit the number of rules for display and calculating the
measures of interest.
''',
inputFormatter:
FilteringTextInputFormatter.digitsOnly, // Integers only
validator: (value) => validateInteger(
value,
min: 2,
),
stateProvider: interestMeasuresAssociationProvider,
enabled: !basketsTicked,
),
variableChooser(
'Sort by:',
associationRulesSortBy,
sortByAssociation,
ref,
sortByAssociationProvider,
tooltip: '''
Refer to ranking rules based on metrics such as support, confidence,
or lift to prioritize the most significant and relevant patterns.
''',
onChanged: (String? value) {
if (value != null) {
ref.read(sortByAssociationProvider.notifier).state = value;
}
},
enabled: !basketsTicked,
),
],
),
],
);
}