-
-
Notifications
You must be signed in to change notification settings - Fork 500
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
Doubt with Provider.of #31
Comments
For example, if: Provider<int>(
value: 42,
child: ...
) is later replaced by: Provider<int>(
value: 24,
child: ... Then this will trigger a rebuild of all widgets that called |
Hi @rrousselGit, is it the way to update the value in a stateful widget? Provider<int>(
value: _value,
child: ...
)
...
// Some widget calls (e.g. onClick event)
setState({
_value = 1234,
})
|
Yes, that's how you should do it. |
@rrousselGit thank you for your confirmation! However, I'm stuck with this for quite long, not sure which part of my codes are wrong. For example: App: MultiProvider(
providers: [
Provider<int>(
value: 123,
child: MaterialApp(
...
),
),
... // other providers
],
)
Screen A: ...
int _value = 0;
...
Widget build(BuildContext context) {
return Provider.of<int>(
value: _value,
child: Scaffold(
...
Button(
onPressed: () {
setState({
_value = 456, // Set value to 456
});
}
),
),
);
}
Screen B: int _value;
Widget build(BuildContext context) {
final _provider = Provider.of<int>(context);
// when access _provider, the value still returns 123 instead of 456
}
|
It looks to me that you have two provides: one in the App and one in Screen A. The value you got in Screen B is from the App, which is a value literal of 123. |
@enetor Initially, Screen A is supposed to change the @enetor @rrousselGit Do you have recommendation on how to update the |
hi, what if we are using ChangedNotifierProvider? will it based on the notifiedListener, instead of value changed? and i suppose it will not rebuild if listen = false right? |
It seems listen parameter is not working in my example, whenever I call setState, it will just rebuild the child widget no matter listen is false or not. Am I doing something wrong? @rrousselGit
|
This should work. class _MyHomePageState extends State<MyHomePage> {
int _counter = 0;
void _incrementCounter() {
setState(() {
_counter++;
});
}
@override
Widget build(BuildContext context) {
return Scaffold(
appBar: AppBar(
title: Text(widget.title),
),
body: Center(
// Center is a layout widget. It takes a single child and positions it
// in the middle of the parent.
child: Provider<int>.value(
value: _counter,
child: Column(
// add `const`
children: const <Widget>[TestStatelessWidget()],
))),
floatingActionButton: FloatingActionButton(
onPressed: _incrementCounter,
child: Icon(Icons.add),
), // This trailing comma makes auto-formatting nicer for build methods.
);
}
}
class TestStatelessWidget extends StatelessWidget {
// add `const` constructor
const TestStatelessWidget();
@override
Widget build(BuildContext context) {
// result is updated anyway, listen = false does not work.
int result = Provider.of<int>(context, listen: false);
return Text("result: $result");
}
} |
Exactly Which is also why provider love const constructors/statelesswidgets |
Hey @rrousselGit and @mono0926, I am having a similar issue to @PandaGeek1024 except that my app (in the following attached document) uses only StatelessWidgets so there is no call to setState anywhere. For that reason, I am not sure what is causing my text widgets to rebuild themselves. I have been trying to figure this out for 2 days now so any insight you could give would be much appreciated. |
This should work. TextField(
onChanged: (newText) {
Provider.of<Data>(context, listen: false).updateValue(newText);
},
) |
@mono0926 |
@Wes1324 |
I believe that the new syntax ( Feel free to correct me if you disagree |
Hello, nice library 馃榾.
can you explain me please what is the difference.
I noticed that I can use in
initState()
ofStatefulWidget
when isfalse
, and can't use when istrue
, but really I don't know why :(Thanks
The text was updated successfully, but these errors were encountered: