You can also create an extension for *attempt()* which would catch only Failures. This way, you prevent unneeded exceptions from being thrown, thus possibly bettering performance.
Cool! When we all learn and use best practices, it is good to understand the difference. Since this simple test bellow shows that with exceptions is much slower 2533 ms versus 9 ms on my workstation. Of course it depends if it is one exception per action or for example function in ListView which iterates over many elements. import 'package:flutter_test/flutter_test.dart'; int validateUnsignedNumber(int number) { if (number < 0) throw FormatException(); return number; } int validateUnsignedNumberNoException(int number) { if (number < 0) return -number; return number; } const ITERATIONS = 1000001; main() { group('exceptions', () { test('should be slower with exceptions', () async { int errors = 0; int iterations = ITERATIONS; while (iterations-- > 0) { try { validateUnsignedNumber(-iterations); } on FormatException { errors++; } } print("errors: $errors"); }); test('should be faster', () async { int nonerrors = 0; int iterations = ITERATIONS; while (iterations-- > 0) { try { validateUnsignedNumberNoException(-iterations); nonerrors++; } on FormatException {} } print("non-errors: $nonerrors"); }); }); }
I am so happy to see FP paradigm making its way to Dart. It was my biggest concern so far, that Dart is very OOPL. With data types such as Either life should be a lot easier thanks to compiler forcing the dev to handle all possible scenarios.
I like the Either class, because you have to implement both cases where you want to use it. But I don't get why I would like to use a Task. I think the code was much more readable with the try catch and you could have simply extracted it into a method. But with this you are using a system that breaks your simple readable error handling introduces a lot of functions, and you even have to introduce another cast to get basically the same result. Like I said, I don't see a benefit there. Did I miss something?
You didn't miss anything. The only difference between the two approaches is that what's described in this tutorial is just pure functional programming (at least, until you call the setPost function, as that's a "side effect")
@@ResoCoder I agree with top comment. I think it's better to leave it at Either. And thank you for making this tutorial, I was the one who requested it! :)
I got a concern. I am not sure how is in Dart but other program languages have performance penalties using throwing exception, which once hit me hard. From that moment I am trying to avoid generating additional exceptions. So I would prefer in your .map implementation instead of try catch - verifying if the obj is Failure and if isn't throw obj. In this example performance penalty will never be visible, but in case you have iteration over many elements it will need improvement. On other hand benefits of proposed change are better readability of code and avoiding creating bad habits. Maybe I am wrong? Does anybody else have similar concerns? BTW: nice video. I like most of your ideas in general. Currently going over your channel searching for additional interesting materials.
Great tutorial. But please do a more advanced and related more to the real world cases such as, how to implement refresh token and retry on API calls in clean architecture. I've been trying this out but it seems like I can't think of the best way to implement it.
I'm glad that someone is doing the same as me - although I have my own Either class, but maybe I should give dartz another try. Hopefully it will become even better when ASTs will land in dart soon. One hint - instead of "if" when building your layout, use "switch", this way compiler will complain, if you forget to check all states from you notifier. also - see you on Flutter Europe!
Great tutorial and perfect timing! Will there be a third part? i'm not exactly sure how to serve cached data in case of failure without major changes to the notifier on setting it into the viewmodel state... for testing purposes would also be great to extract the state notifier in another ChangeNotfier and inject it with dependencies.
Always awesome. Dear Reso Coder, I've learn a lot from those tutorials you've uploaded, Thank you very much!!!. If I can make a request, please, please, please make tutorials regarding functional programming in android with Arrow and Kotlin.
If anybody see this comment please help me. I want work with a list instead of single object . In case of pagination I received first list then how I can combine newly got list and previous list in either . By the way the tutorial was amazing expecting a lot from you resocoder
You can also create an extension for *attempt()* which would catch only Failures. This way, you prevent unneeded exceptions from being thrown, thus possibly bettering performance.
Cool!
When we all learn and use best practices, it is good to understand the difference.
Since this simple test bellow shows that with exceptions is much slower 2533 ms versus 9 ms on my workstation.
Of course it depends if it is one exception per action or for example function in ListView which iterates over many elements.
import 'package:flutter_test/flutter_test.dart';
int validateUnsignedNumber(int number) {
if (number < 0) throw FormatException();
return number;
}
int validateUnsignedNumberNoException(int number) {
if (number < 0) return -number;
return number;
}
const ITERATIONS = 1000001;
main() {
group('exceptions', () {
test('should be slower with exceptions', () async {
int errors = 0;
int iterations = ITERATIONS;
while (iterations-- > 0) {
try {
validateUnsignedNumber(-iterations);
} on FormatException {
errors++;
}
}
print("errors: $errors");
});
test('should be faster', () async {
int nonerrors = 0;
int iterations = ITERATIONS;
while (iterations-- > 0) {
try {
validateUnsignedNumberNoException(-iterations);
nonerrors++;
} on FormatException {}
}
print("non-errors: $nonerrors");
});
});
}
can you explain more?
I am so happy to see FP paradigm making its way to Dart. It was my biggest concern so far, that Dart is very OOPL. With data types such as Either life should be a lot easier thanks to compiler forcing the dev to handle all possible scenarios.
I like the Either class, because you have to implement both cases where you want to use it. But I don't get why I would like to use a Task.
I think the code was much more readable with the try catch and you could have simply extracted it into a method. But with this you are using a system that breaks your simple readable error handling introduces a lot of functions, and you even have to introduce another cast to get basically the same result.
Like I said, I don't see a benefit there. Did I miss something?
You didn't miss anything. The only difference between the two approaches is that what's described in this tutorial is just pure functional programming (at least, until you call the setPost function, as that's a "side effect")
@@ResoCoder I agree with top comment. I think it's better to leave it at Either.
And thank you for making this tutorial, I was the one who requested it! :)
Well at least now i know there is one more way to handle error (using Task) which i can look at when required !!
I got a concern.
I am not sure how is in Dart but other program languages have performance penalties using throwing exception, which once hit me hard. From that moment I am trying to avoid generating additional exceptions. So I would prefer in your .map implementation instead of try catch - verifying if the obj is Failure and if isn't throw obj.
In this example performance penalty will never be visible, but in case you have iteration over many elements it will need improvement.
On other hand benefits of proposed change are better readability of code and avoiding creating bad habits.
Maybe I am wrong? Does anybody else have similar concerns?
BTW: nice video. I like most of your ideas in general. Currently going over your channel searching for additional interesting materials.
Read the pinned comment, please. Thanks for pointing this out!
Great tutorial. But please do a more advanced and related more to the real world cases such as, how to implement refresh token and retry on API calls in clean architecture. I've been trying this out but it seems like I can't think of the best way to implement it.
thanks for such a good tutorial (2023)
I'm glad that someone is doing the same as me - although I have my own Either class, but maybe I should give dartz another try. Hopefully it will become even better when ASTs will land in dart soon. One hint - instead of "if" when building your layout, use "switch", this way compiler will complain, if you forget to check all states from you notifier.
also - see you on Flutter Europe!
But switch is so... You know 😄
See you there!
and what happens if you want to cast to the right? There is no rightMap?
Great tutorial and perfect timing! Will there be a third part? i'm not exactly sure how to serve cached data in case of failure without major changes to the notifier on setting it into the viewmodel state... for testing purposes would also be great to extract the state notifier in another ChangeNotfier and inject it with dependencies.
Always awesome. Dear Reso Coder, I've learn a lot from those tutorials you've uploaded, Thank you very much!!!. If I can make a request, please, please, please make tutorials regarding functional programming in android with Arrow and Kotlin.
If anybody see this comment please help me. I want work with a list instead of single object . In case of pagination I received first list then how I can combine newly got list and previous list in either . By the way the tutorial was amazing expecting a lot from you resocoder
Very valuable video!!! Thanks!
Quality Tutorial 👍
These tutorials are awesome :D
Thank you!
was waiting for this...
Aaand now it's here!
very difficult
Flutter GDE when? XD
Hi from 2022