searchTextField method
build a widget, a State.setState call would require Flutter to entirely
rebuild the returned wrapping widget. If a Widget was used instead,
Flutter would be able to efficiently re-render only those parts that
really need to be updated. Even better, if the created widget is const
,
Flutter would short-circuit most of the rebuild work.
-
Avoid changing the depth of any created subtrees or changing the type of any widgets in the subtree. For example, rather than returning either the child or the child wrapped in an IgnorePointer, always wrap the child widget in an IgnorePointer and control the IgnorePointer.ignoring property. This is because changing the depth of the subtree requires rebuilding, laying out, and painting the entire subtree, whereas just changing the property will require the least possible change to the render tree (in the case of IgnorePointer, for example, no layout or repaint is necessary at all).
-
If the depth must be changed for some reason, consider wrapping the common parts of the subtrees in widgets that have a GlobalKey that remains consistent for the life of the stateful widget. (The KeyedSubtree widget may be useful for this purpose if no other widget can conveniently be assigned the key.)
{@tool snippet}
This is a skeleton of a stateful widget subclass called YellowBird
.
In this example. the State has no actual state. State is normally
represented as private member fields. Also, normally widgets have more
constructor arguments, each of which corresponds to a final
property.
class YellowBird extends StatefulWidget {
const YellowBird({ Key? key }) : super(key: key);
@override
State<YellowBird> createState() => _YellowBirdState();
}
class _YellowBirdState extends State<YellowBird> {
@override
Widget build(BuildContext context) {
return Container(color: const Color(0xFFFFE306));
}
}
{@end-tool} {@tool snippet}
This example shows the more generic widget Bird
which can be given a
color and a child, and which has some internal state with a method that
can be called to mutate it:
class Bird extends StatefulWidget {
const Bird({
Key? key,
this.color = const Color(0xFFFFE306),
this.child,
}) : super(key: key);
final Color color;
final Widget? child;
@override
State<Bird> createState() => _BirdState();
}
class _BirdState extends State<Bird> {
double _size = 1.0;
void grow() {
setState(() { _size += 0.1; });
}
@override
Widget build(BuildContext context) {
return Container(
color: widget.color,
transform: Matrix4.diagonal3Values(_size, _size, 1.0),
child: widget.child,
);
}
}
{@end-tool}
By convention, widget constructors only use named arguments. Also by
convention, the first argument is key
, and the last argument is child
,
children
, or the equivalent.
See also:
- State, where the logic behind a StatefulWidget is hosted.
- StatelessWidget, for widgets that always build the same way given a particular configuration and ambient state.
- InheritedWidget, for widgets that introduce ambient state that can be read by descendant widgets.
Implementation
// An annotation used by test_analysis package to verify patterns are followed
// that allow for tree-shaking of both fields and their initializers. This
// annotation has no impact on code by itself, but indicates the following pattern
// should be followed for a given field:
//
// ```dart
// class Foo {
// final bar = kDebugMode ? Object() : null;
// }
// ```
searchTextField() {
return Padding(
padding: const EdgeInsets.only(left: 20.0, right: 20.0),
child: Container(
height: 56,
decoration: BoxDecoration(
color: const Color(0xff6A6A79),
borderRadius: BorderRadius.circular(28)),
child: Row(
crossAxisAlignment: CrossAxisAlignment.center,
children: [
Padding(
padding: const EdgeInsets.only(left: 16.0, right: 8),
child: Image.asset('assets/images/searchcolor.png', height: 18,color: Colors.white,),
),
],
),
),
);
}