What are Keys in the Stateless widgets class? - dart

In the flutter docs there's sample code for a stateless widget subclass as shown:
class GreenFrog extends StatelessWidget {
const GreenFrog({ Key key }) : super(key: key);
#override
Widget build(BuildContext context) {
return new Container(color: const Color(0xFF2DBD3A));
}
}
and this
class Frog extends StatelessWidget {
const Frog({
Key key,
this.color: const Color(0xFF2DBD3A),
this.child,
}) : super(key: key);
final Color color;
final Widget child;
#override
Widget build(BuildContext context) {
return new Container(color: color, child: child);
}
}
What is a key and when should this super constructor be used? It seems like if you have your own constructor you must have {Key key} why? I've seen other examples where the super keyword is not used so this is where my confusion is.

TLDR: All widgets should have a Key key as optional parameter or their constructor.
Key is something used by flutter engine at the step of recognizing which widget in a list as changed.
It is useful when you have a list (Column, Row, whatever) of widgets of the same type that can potentially get removed/inserted.
Let's say you have this (code not working, but you get the idea) :
AnimatedList(
children: [
Card(child: Text("foo")),
Card(child: Text("bar")),
Card(child: Text("42")),
]
)
Potentially, you can remove any of these widgets individually with a swipe.
The thing is, our list has an animation when a child is removed. So let's remove "bar".
AnimatedList(
children: [
Card(child: Text("foo")),
Card(child: Text("42")),
]
)
The problem: Without Key, flutter won't be able to know if the second element of your Row disappeared. Or if it's the last one that disappeared and the second has its child change.
So without Key, you could potentially have a bug where your leave animation will be played on the last element instead!
This is where Key takes place.
If we start our example again, using key we'd have this :
AnimatedList(
children: [
Card(key: ObjectKey("foo"), child: Text("foo")),
Card(key: ObjectKey("bar"), child: Text("bar")),
Card(key: ObjectKey("42"), child: Text("42")),
]
)
notice how the key is not the child index but something unique to the element.
From this point, if we remove "bar" again, we'll have
AnimatedList(
children: [
Card(key: ObjectKey("foo"), child: Text("foo")),
Card(key: ObjectKey("42"), child: Text("42")),
]
)
Thanks to key being present, flutter engine now knows for sure which widget got removed. And now our leave animation will correctly play on "bar" instead of "42".

What are Keys?
Keys are IDs for widgets. All widgets have them, not just StatelessWidgets. They are used by the Element tree to determine if a widget can be reused or if it needs to be rebuilt. When no key is specified (the usual case), then the widget type is used to determine this.
Why use Keys?
Keys are useful for maintaining state when the number or position of widgets changes. If there is no key then the Flutter framework can get confused about which widget changed.
When to use Keys?
Only use them when the framework needs your help to know which widget to update.
Most of the time you don't need to use keys. Since keys are mostly only useful for maintaining state, if you have a stateless widget whose children are all stateless, then there is no need to use a key on it. It won't hurt to use a key in this case, but it also won't help.
There are some micro-optimizations you can make using keys. See this article.
Where to use Keys?
Put the key at the part of the widget tree where the reordering or addition/deletion is taking place. For example, if you are reordering the items of a ListView whose children are ListTile widgets, then add the keys to the ListTile widgets.
What kind of Keys to use?
A key is just an id, but the kind of ID you use can vary.
ValueKey
A ValueKey is a local key that takes a simple value like a string or integer.
ObjectKey
If you widget is displaying more complex data than a single value, then you can use an ObjectKey for that widget.
UniqueKey
This type of key is guaranteed to give you a unique ID every time. If you use it, though, do NOT put it in the build method. Otherwise your widget will never have the same ID and so the Element tree will never find a match to reuse.
GlobalKey
GlobalKeys can be used to maintain state across your app, but use them sparingly because they are similar to global variables. It is often preferable to use a state management solution instead.
Examples of using Keys
AnimatedLists
Changing the position in a column/row
TextFormField
References
Keys! What are they good for?
Using Keys in Flutter

Key is object that is used to identify a widget uniquely.
They are used to access or restore state In a StatefulWidget (Mostly we don't need them at all if our widget tree is all Stateless Widgets).
There are various types of key that I will try to explain on the basis of usage.
Purpose (key types)
1. Mutate the collection i.e. remove / add / reorder item to list in stateful widget like draggable todo list where checked items get removed
➡️ ObjectKey, ValueKey & UniqueKey
2. Move widget from one Parent to another preserving it's state.
➡️ GlobalKey
3. Display same Widget in multiple screens and holding its state.
➡️ GlobalKey
4. Validate Form.
➡️ GlobalKey
5. You want to give a key without using any data.
➡️ UniqueKey
6. If you can use a certain fields of data like UUID of users as unique Key.
➡️ ValueKey
7. If you do not have any unique field to use as key but object itself is unique.
➡️ ObjectKey
8. If you have multiple Forms or Multiple Widgets of the same type that need GlobalKey.
➡️ GlobalObjectKey, LabeledGlobalKey whichever is appropriate, similar logic to ValueKey and ObjectKey
❌ Do not use random string/number as key, it defeats the purpose of keys ❌

The Key is an optional parameter needed to preserve state in your widget tree, you have to use them if you want to move a collection of elements in your tree and preserve the state of them.
The best explanation can be found in this video by Google When to Use Keys - Flutter Widgets 101 Ep. 4

With Dart 2.12 or later, add ? after Key to make it optional if you want.
class Frog extends StatelessWidget {
const Frog({
Key? key,
this.color: const Color(0xFF2DBD3A),
this.child,
}) : super(key: key);
final Color color;
final Widget child;
#override
Widget build(BuildContext context) {
return new Container(color: color, child: child);
}
}

Related

List<MyType> to <Widget>

I am trying to understand the casting system of Dart, in specific with flutter.
I have a List of my custom type I would like to fill in a TableRow, but I simply fail to use map for it. Can anyone help me to point out what my problem is? At the end I need a list of widgets for the children parameter.
TableRow(
children: myList.map((MyType foo) {
return <Widget>[new Text(foo.name)];
}) as List<Widget>
),
The error I am getting is:
flutter: type 'MappedListIterable<MyType, List<Text>>' is not a subtype of type 'List<Widget>' in type cast
Any help is highly appreciated
Just do this:
TableRow(
children: myList.map((foo) {
return new Text(foo.name);
}).toList(),
),
As Rémi says, you need to return a widget inside the map() function, not a list of widgets. And then convert the iterable to a List with toList() method.

Widget re-render when I focus on a TextField - Bloc Pattern

I'm using a BLoC to keep state between two nested FullScreenDialogs.
I'm initializing the bloc when I push the first screen, like so
return FloatingActionButton(
child: Icon(Icons.add),
onPressed: () {
Navigator.of(context).push(MaterialPageRoute(
builder: (BuildContext context) => ProductBlocProvider(child: ProductEntryScreen()),
fullscreenDialog: true
));
},
);
ProductEntryScreen has a bunch of TextFields and a button than opens a new FullScreenDialog. This new Screen also has TextFields.
The problem I'm having is that every time I write on a TextField on the second FullScreenDialog, the onPressed function where I start the ProductBlocProvider runs again.
And that re-run is causing the Bloc to create a new instance, so I end up loosing the state.
What I want to do?
Maybe I'm doing it wrong so I'll explain what I'm trying to achieve.
I want to keep state between the two FullScreenDialogs while I fill all the fields, and when I'm done I want to press a button that send all of the data (both screens) to a database.
The problem is that I was creating the instance of the bloc inside the provider in the builder function of the MaterialPageRoute.
That builder function was being called repeatedly, and creating a new instance of the bloc every time. The solution was to take out from the builde function the creation of the bloc instance, like this:
return FloatingActionButton(
child: Icon(Icons.add),
onPressed: () {
//Here I create the instance
var _bloc = ProductBloc();
Navigator.of(context).push(MaterialPageRoute(
//And I pass the bloc instance to the provider
builder: (BuildContext context) => ProductBlocProvider(bloc: _bloc, child: ProductEntryScreen()),
fullscreenDialog: true
));
},
);
The package get_it may be of help to you. get_it is a service locator library, and uses a Map to store the registered objects; therefore, it provides access at a complexity of O(1), which means it's incredibly fast. The package comes with a singleton GetIt which you can use like so,
// Create a global variable (traditionally called sl or locator)
final sl = GetIt.instance; // There is also a shorthand GetIt.i
// ...
// Then, maybe in a global function called initDi(),
// you could register your dependencies.
sl.registerLazySingleton(() => ProductBloc());
registerLazySingleton() or registerSingleton() will always
return the same instance; lazily (i.e., when first called)
or at app start-up respectively.
If you want to create a new instance every time, use registerFactory() instead (I put this here even though it's not exactly what you want).
For example,
sl.registerFactory(() => ValidatorCubit());
And it could be accessed like this,
MultiBlocProvider(
providers: [
// The type is inferred here
BlocProvider<AuthenticationBloc>(create: (_) => sl()),
// The type is explicitly given here
BlocProvider(create: (_) => sl<ProductsBloc>()),
],
child: ProductsScreen(),
),
This example primarily shows you how it can be done with the flutter_bloc library, but get_it works anywhere, even in non-flutter dart projects.
If you need more functionality, do make sure to read the docs for this package. It is well documented, and contains (almost) every feature you might need, including scoping.
Also, this approach allows you to use the interface pattern, making the code much more maintainable and testable, as you will have to change just one place to use a different implementation.

IndexedWidgetBuilder, how does it know the index?

This is mostly a conceptual question as I'm new to Dart and I guess I'm not understanding the semantics of the language here.
In IndexedWidgetBuilder,
Widget IndexedWidgetBuilder (
BuildContext context,
int index
)
who exactly is giving a value to index?
When this "thing" is used, for example:
itemBuilder: (context, i) {
blablabla
},
"context" and "i" are never initialized and they magically have a value. Who is defining this value and where?
IndexedWidgetBuilder is a typedef that defines a function that takes a BuildContext and an int, and returns a Widget.
/// Signature for a function that creates a widget for a given index, e.g., in a
/// list.
///
/// Used by [ListView.builder] and other APIs that use lazily-generated widgets.
typedef Widget IndexedWidgetBuilder(BuildContext context, int index);
So, when defining itemBuilder you are providing the Widget with a function that it can call, when it wants to build an item. When the Widget is building itself it will call this function many times to build each of its children. Simplistically, it may call this function with i=0, then 1, then 2, etc.
If your Widget only has 3 children, it would be easier to just pass then as a List, but if your Widget has a thousand children this would be inefficient - and this is where the builder comes in. The Widget will try to only call the itemBuilder function for the child widgets that it actually needs, and not for any that are, say, off the top or bottom of the screen.
So, to answer your question, the Widget passes the context and i to your itemBuilder function when it calls it (typically multiple times) to build some or all of its children. i represents the ith child, so that your builder function knows which child it is being asked to build.
Edit
The dartdoc of IndexedWidgetBuilder says that it is used by ListView.builder.
The dartdoc of ListView.builder says
Providing a non-null itemCount improves the ability of the [ListView]
to estimate the maximum scroll extent. The itemBuilder callback will
be called only with indices greater than or equal to zero and less
than itemCount. The itemBuilder should actually create the widget
instances when called.
The ListView.builder named constructor constructs a SliverChildBuilderDelegate, passing in the itemBuilder as builder.
It gets used in the SliverChildBuilderDelegate's build method, here:
#override
Widget build(BuildContext context, int index) {
assert(builder != null);
if (index < 0 || (childCount != null && index >= childCount))
return null;
Widget child = builder(context, index); // <- your callback is called
if (child == null)
return null;
if (addRepaintBoundaries)
child = new RepaintBoundary.wrap(child, index);
if (addAutomaticKeepAlives)
child = new AutomaticKeepAlive(child: child);
return child;
}
So, index comes from the SliverChildBuilderDelegate's build method. You could keep walking backwards to see who calls that.

ListView.builder not showing correct list

I've created a small app to add items in list, however when i delete something from list, it gets deleted successfully but ListView.builder doesn't show correct values. i know its something related to keys given to class but i'm pretty new in flutter so don't know how to do that.
Gist: https://gist.github.com/OculusMode/213052325ec725aad3ab92c73599b187
Thanks in advance.!
Add this to constructor of your Widget:
:super(key:new ObjectKey(_data))
Example:
class TodoTile extends StatefulWidget {
String _data;
int _index;
ValueChanged<int> onDelete;
TodoTile(this._data,this._index,{ #required this.onDelete , Key key}):super(key:new ObjectKey(_data));
TodoTileState createState() {return new TodoTileState(_data, _index,this.onDelete);}
}
Not sure if this would cause problems too but I've also changed widget.onDelete to onDelete (passing the function pointer to the state too)
Source:
https://flutter.io/widgets-intro/#keys

Flutter: Retrieving top-level state from child returns null

I'm trying to obtain the top-level state of my app using a .of()-method, similar to the Scaffold.of() function. This is the (stripped down) code:
class IApp extends StatefulWidget {
#override
IAppState createState() => new IAppState();
static IAppState of(BuildContext context) =>
context.ancestorStateOfType(const TypeMatcher<IAppState>());
}
The app is started using runApp(new IApp)
This Widget creates a HomePage:
#override
Widget build(BuildContext context) {
return new MaterialApp(
// ommitted: some localization and theming details
home: new HomePage(),
);
}
Then, I try to access the State from the HomePage (a StatefulWidget itself):
#override
Widget build(BuildContext context) {
return new Scaffold(
// ommited: some Scaffold properties such as AppBar
// runtimeType not actual goal, but just for demonstration purposes
body: new Text(IApp.of(context).runtimeType.toString()),
);
}
The strange this is, the code works when I place the code for HomePage in the same file as the IApp, but just as an extra class. However, when I place HomePage in a separate file (main.dart and homepage.dart importing each other), the return value of IApp.of(context) is null.
What causes this? And how can I fix it?
TDLR: imports file only using
import 'package:myApp/path/myFile.dart';
Never with
import './myFile.dart';
This is due to how dart resolves imports.
You may have a single source file, but during builds, there is some kind of duplicates.
Let's say you're working on 'myApp'. To import a file, you could do both :
import 'relativePath/myFile.dart'
import 'package:myApp/path2/myFile.dart'
You'd think that they point to the same file right?
But no. One of them will point to the original source. While the other one will point to a temporary file used for the build.
The problem comes when you start to mix both solutions. Because for the compiler, these two files are different. Which means that IApp imported from package:myApp/IApp is not equal to the same IApp imported from relativePath/myApp/IApp
In your case, you inserted in your widget tree an IApp from pakage:path but your IApp.of(context) use IAppState resolved locally.
They both have a different runtimeType. Therefore const TypeMatcher<IAppState>() won't match. And your function will return null.
There's an extremely easy way to test this behavior.
Create a test.dart file containing only
class Test {
}
then in your main.dart add the following imports :
import 'package:myApp/test.dart' as Absolute;
import './test.dart' as Relative;
You can finally test this by doing :
new Relative.Test().runtimeType == new Absolute.Test().runtimeType
Spoiler: the result is false
Now you can use the relative path.
You can verify this, as Remy suggested two years ago:
Relative.Test().runtimeType == Absolute.Test().runtimeType
Spoiler: the result is true

Resources